From wang!elf.wang.com!ucsd.edu! packet-radio-relay Sat Mar 23 21:42:10 1991 remote 
from tosspot 
Received: by tosspot (1.63/waf) 
via UUCP; Sat, 23 Mar 91 20:35:56 EST 
for lee 
Received: from somewhere by elf.wang.com 
id aa24637; Sat, 23 Mar 91 21:42:08 GMT 
Received: from ucsd.edu by news.UU.NET with SMTP 
(5.61/UUNET-shadow-mx) id AAQ06109; Sat, 23 Mar 91 15:12:49 -0500 
Received: by ucsd.edu; id AA10456 
sendmail 5.64/UCSD-2.1-sun 
Sat, 23 Mar 91 04:30:27 -0800 for brian 
Received: by ucsd.edu; id AA10451 
sendmail 5.64/UCSD-2.1-sun 
Sat, 23 Mar 91 04:30:14 -0800 for /usr/lib/sendmail -oc -odb -0Q/var/spool/ 
lqueue -oi -fpacket-radio-relay packet-radio-list 
Message-Id: <9103231230.AA10451@ucsd.edu> 
Date: Sat, 23 Mar 91 04:30:06 PST 
From: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu> 
Reply-To: Packet-Radio@ucsd.edu 
Subject: Packet-Radio Digest V91 #69 
To: packet-radio@ucsd.edu 


Packet-Radio Digest Sat, 23 Mar 91 Volume 91 : Issue 69 


Today's Topics: 
Administrivia 
? how to route with tcpip (2 msgs) 
Anonymous ftp site for BayComm ??? (2 msgs) 
anybody RUNNING 9600 ?? (2 msgs) 
APLINK 
Baycom Circuit Wanted 
Class C IP address for packet radio? 
Dayton - Digital Suite? 
Digital repeater network 
G3RUH 9600 baud users on UO-14 
Hierarchical Forwarding pounds (#) (13 msgs) 
How to get email from packet??? 
Inadvertant "clear screen" (4 msgs) 
KA9Q & mbox BBS forwarding 
KAIQ v910308 problems 
KAM dual-mode enhancement 
Monthly On-Line Elmers Resource Directory (2 msgs) 
New packet user 
No Subject 
Packet BBS SID and personal mbox reverse forward 
PK-88 Pinouts (2 msgs) 


portable packet (4 msgs) 
SMTP Mail on PBBS? 
STS-37 SAREX Information Summary 
TAPR meeting notes 
TCP/IP 
Thanks 
The Amateur Radio BBS - How to access 
The N2GTE Packet Mail Switch 
TNC Emulators on PC's (3 msgs) 
WANTED: Docs for NETPC (DL3DBT v891105) 
Where can I download Baycom? 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Fri, 22 Mar 91 14:04:58 -0800 
From: brian (Brian Kantor) 

Subject: Administrivia 

To: info-ham-digest, packet-radio-digest 


Sorry about the deluge of digests; I just fixed the gateway and we had 10 
days worth of traffic to catch up on. Things should tame out now. 


As many of you know, these mailing lists are gatewayed bidirectionally with 
newsgroups on Usenet. Recently those newsgroups underwent a reorganization, 
with the ham-radio group being split into several groups, primarily splitting 
off a "policy" group for the discussion of things like no-code, license 
classes, rules and regulations, etc. 


That newsgroup is now available as a separate digest from ucsd, the ham-policy 
digest. You may subscribe, as always, by sending mail to listserv@ucsd.edu. 


Now that everything is working, I'm going on vacation for a week. Flames will 
be extinguished when I get back. 


- Brian 


Date: 23 Mar 91 02:46:37 GMT 


From: usc!samsung!munnari.oz.au!manuel!csc.canberra.edu.au!echo!skcm@ucsd.edu 
Subject: ? how to route with tcpip 
To: packet-radio@ucsd.edu 


In <1991Mar22.193108.10649@xanadu.com> jeff@xanadu.com (Jeff Crilly N6ZFX) writes: 


>It seems that this should be doable without have to change the routing 
>table (using arp and route add) on kg6kf£. If not, then everyone has to be 
>able to hear everyone else; and only direct connections would be possible. 


I haven't found a way yet. :-( I have a similar problem here in Canberra. 
Hidden Transmitters are the norm. The only solution we have come up with 
is to have every station you want to talk to that isn't direct pointed to 
by a route and/or arp entry and they also have to have you defined. 


We have another problem here in Australia. IP routing isn't legal over the 
air. (Yet, we're trying) To talk to stations out of line of site we HAVE to 
use digipeaters. :-( Usually we end up having all the people we normally 
talk to defined to ARP with a digipeater chain. :-( 


Carl. 


Date: 23 Mar 91 01:51:06 GMT 

From: swrinde!zaphod.mps.ohio-state.edu!usc! apple! fernwood!portal!cup.portal.com! 
Jeepster@ucsd.edu 

Subject: ? how to route with tcpip 

To: packet-radio@ucsd.edu 


>... So the question is, how can I get arp to send to kg6kf via wn6i-7 
>instead of replying directly? 


You might try adding the following "route" entry: 
ax25 route add kg6kf wn6i-7 


That's what I had to do to get to a local tcp/ip station thru a digi. 


John, KFOOU 
jeepster@cup.portal.com 
k£Oou@kfOou.ampr.org [44.20.0.38] Good luck, hope it helps! 


Date: 13 Mar 91 16:44:03 GMT 
From: bonnie.concordia.ca!s3!mlefebvr@uunet.uu.net 
Subject: Anonymous ftp site for BayComm ??? 


To: packet-radio@ucsd.edu 


I am looking for a anonymous ftp site from which I could get BayComm. 
Is there such a site somewhere ? Thank you. 


Marc, VE2HQT 


Marc Lefebvre, IREQ: Institut de Recherche d'Hydro-Quebec 

Analyste Ressources Informatiques 1802 Montee Ste-Julie, Varennes, 
Prov. Quebec, CANADA J3X 1S1. 

mlefebvr@ireq.hydro.qc.ca Tel: 514 652-8554 fax: 514 652-8555 


Date: 15 Mar 91 15:04:39 GMT 

From: orion.oac.uci.edu!ucivax!jarthur!elroy.jpl.nasa.gov!swrinde! zaphod.mps.ohio- 
state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic! 

news. funet.f£i!kannel!huopio@ucsd.edu 

Subject: Anonymous ftp site for BayComm ??? 

To: packet-radio@ucsd.edu 


> I am looking for a anonymous ftp site from which I could get BayComm. 
> Is there such a site somewhere ? Thank you. 


> Marc, VE2HQI 


Date: 13 Mar 91 15:43:37 GMT 
From: norand! lusere@uunet.uu.net 
Subject: anybody RUNNING 9600 ?? 
To: packet-radio@ucsd.edu 


I am interested in anyone's experiences in modifying and OPERATING 
commercial and ham equipment to operate 4800-9600 baud packet. 


This question is concerned with modifying FM radios for terrestrial links, 
not satellite work through SSB equipment. 


In particular, I'd like to hear any experiences with setting up the radios 
and what performance figures are being seen (like dBm for 10-6 BER, 
bandwidths for various baudrates, deviation values that worked, radios 
that worked better than others, etc.) 


I would like to try to use the older rock-bound commercial gear like Micors, 


Maxars, MASTR EXEC's, etc. 
Email is fine, I will summarize and re-post what I hear by that means. 
Thanks, 


Ron Luse, KD9KX 

Norand Data Systems 

Cedar Rapids, Iowa 

uunet!norand!ron | norand!ron@uunet.uu.net | kd9kx @ waOrjt.ia 


Date: 13 Mar 91 18:52:48 GMT 
From: brian@ucsd.edu 

Subject: anybody RUNNING 9600 ?°? 
To: packet-radio@ucsd.edu 


In article <47@norand.UUCP> lusere@norand.UUCP (Ron Luse) writes: 

>I am interested in anyone's experiences in modifying and OPERATING 
>commercial and ham equipment to operate 4800-9600 baud packet. 

>I would like to try to use the older rock-bound commercial gear like Micors, 
>Maxars, MASTR EXEC's, etc. 


I have been modifying several of these kinds of radios for 9600 bps 
operation recently. 


The MASTR Exec-II won't do it easily; it's got a phase modulator and 
won't do flat dev. The receiver works fine, so we'd thought about 
shoving the modulation into the temperature compensation voltage line 
to see if we could move the tempcomp varicap around to get true FM. 
That might work, but we never got around to trying it. 


The old lowband Mocom-70 will work at 9600 bps, but our experience is 
that you really need to use them at 4800, because they have enough 
frequency drift that the IF might wind up shaving off the edges of 
received signals if one end is drifting opposite the other. 


The MICOR will work just fine on 450 MHz, since there is a direct-FM 
modulator on the TX offset oscillator. The highband and some lowband 
models have phase modulators, which won't work, and the serrasoid 
modulator on lowband is hopeless. I did have success in using a 450 
channel element in a highband Micor TX, and shoving the modulation into 
the AFC input of the element, but it wasn't real clean. All bands have 
plenty of receive IF bandwidth. 


The Maxar is ideal because its transmitter has a direct-fm varicap 
modulator. You just pop one end of the 10uF DC blocking cap off and 


feed the modem into there. The receiver has sufficient IF bandwidth 
but the detector is loaded down by the deemphasis network that hangs 
off pin 6 of the detector chip; just chop off the 2.7k resistor and 

take the output directly from pin 6 to the modem. 


The Mitrek is pretty much the same as the MAXAR except that you have to 
feed the transmit modulation directly into the modulation input line 
for the channel element, since the previous stage is part of the 
splatter lowpass filter. We'll be using Mitreks on the hill since 

they have a much better front end than the Maxar does. 


Hope that helps. 
- Brian 


Date: 20 Mar 91 02:20:42 GMT 

From: swrinde!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!think.com! linus! 
linus!mwunix.mitre.org!m21198@ucsd.edu 

Subject: APLINK 

To: packet-radio@ucsd.edu 


If that is not the required syntax for a posting a certain "Elmer" is 
going to suffer the Wouff Hong. 


I, and I presume others, would like some information on APLINK bulletin 
board systems. They seem to be fairly common on hf Amtor and to be linked 
with the national BBS system. I would like to know: 

x What is APLINK 

*x What can it do 

x How is it linked to the rest of the world 

*x Where can the software to run it be obtained (APLINK 5.03) 

* How is the frequency/band/beam heading scanning accomplished 

*x Any other lurid details: Enquiring minds want, you know 


Thanks: John WA9FCH McHarry@MITRE.org 


Date: 14 Mar 91 18:16:00 GMT 

From: rosevax!bert.Rosemount.COM!mikef@uunet.uu.net 
Subject: Baycom Circuit Wanted 

To: packet-radio@ucsd.edu 


I am looking for the schematic for the circuit as described in 
the "BAYCOM" documentation. 


I realize that there are boards available for the DIGICOM version, 


but this requires an external power supply. 


The circuit for the BAYCOM gets power from the RS232 port to power 
the board. The documentation suggests sending 89 Deutch Marks 

to an adress in Germany, but I don't have a readily available 
source for the Deutch Marks and I don't think that I want to send 
cash (even German) thru the mail. 


I don't know how else to send for it or how long it would take 
if I did find a way to order thru Germany. 


Does anyone have a copy of the schematic for this circuit or 
suggestions on how to order it? 


Mikef@bert.rosemount.com 


Date: 19 Mar 91 03:52:39 GMT 

From: usc!zaphod.mps.ohio-state.edu! uwm.edu! bionet!hayes.ims.alaska.edu! 
acad3.alaska.edu!ftpam1@ucsd.edu 

Subject: Class C IP address for packet radio? 

To: packet-radio@ucsd.edu 


I have some questions for the amateur radio IP community. I have 
an Arcnet LAN and have been thinking about getting a Class C IP network 
address for it. This would greatly simplify some projects that I am 
working on. However, there appear to be some pitfalls. Questions follow: 


1. How many of you have Net 44 dependant routing? For an example with 
KA9IQ, Net 44 packets are routed to a KISS serial port and everything 
else is routed to a campus Ethernet ultimately connected to Internet. 


2) How many of you have amateur radio IP nodes with addresses outside 
Net 44? Have you had problems with routing as described above? 


Philip Munts N7AHL 
NRA Extremist, etc. 
University of Alaska, Fairbanks 


Date: 18 Mar 91 18:24:16 GMT 

From: pilchuck!ssc!tad@uunet.uu.net 
Subject: Dayton - Digital Suite? 
To: packet-radio@ucsd.edu 


In article <3866@mjbtn.JOBSOFT.COM>, root@mjbtn.JOBSOFT.COM (Mark J. Bailey) 


writes: 
Hi, 


Who all is planning to go to Dayton this year? War's over, travel is probably 
getting safer again, economy may rebound.... 


Also, will there be another gathering of the "Digital Suite" at the Stouffer 
and if so, same place, same day (Friday) and time? 


VV VV VV WV 


I organized the Digital Suite at Stouffers last year. I'm not going to 
Dayton this year. The Digital Suite was a one time thing on my part. 

A friend had reserved the Orville Wright Suite the year before, then 
didn't use it. He gave it to me for free, and I thought it would be 
fun to gather usenet/fidonet/packet/RTTY hams for a party. It 

was great fun, but NO WAY could I ever afford to do this again, at 
least with my money. 


Tad Cook 

Seattle, WA 

Packet: KT7H @ N7ENT.d4WWA.WA.USA.NA 
Phone: 206/527-4089 

MCI Mail: 3288544 

Telex: 6503288544 MCI UW 

USENET: ...uw-beaver!sumax!amc-gw!ssc!tad 
or, tad@ssc.UUCP 


Date: 13 Mar 91 21:29:21 GMT 

From: sdd.hp.com!caen!sol.ctr.columbia.edu!cunix£.cc.columbia.edu! 
cunixb.cc.columbia.edu!mig@ucsd.edu 

Subject: Digital repeater network 

To: packet-radio@ucsd.edu 


Has anyone looked into the feasibility of creating a digital repeater network? 
It seems to me that this would allow most any ham to talk to most any other, 
anywhere, uSing a simple handheld radio. This seems like a logical extension 
of the current plans to create an analog system using dynamic links to a 

long distance backbone. The problem with this scheme is: what happens 

if a link in the backbone fails; and if more than one user wants to use the 
system at the same time? It would be a very resource intensive system, 
anyway. 


In short: why couldn't the Amateur community set up the equivalent of a 
digital cellular network with modest user requirements, linked exclusively 
by radio and therefore immune to damage to the hard-wired systems such as 
the telephone network. 


Phil: can you hear me? 


kK kK Ke KKK =——— = = — — — — —— — ——_—— —— Meir Green 
Sele ale sles eale cies “ale. ale -G = = = = SS = SS SSS SS SSS SS mig@cunixb.cc.columbia.edu 
KKK KKK SSS >> >= >>> N2I3PG 


Date: 14 Mar 91 19:01:54 GMT 

From: swrinde!zaphod.mps.ohio-state.edu! samsung! rex! rouge!pc.usl.edu! jpd@ucsd.edu 
Subject: G3RUH 9600 baud users on UO-14 

To: packet-radio@ucsd.edu 


Here's a list of users and their equipment summary, of satellite UO-14. 
This pacsat operates at 9600 baud full duplex. 


*xU0-14 Users List rev.10 Compiled by JA6FTL 03-10-1990 


Uploader:18 Countries 84 stations are counted (~ Mar.10) 
CT1DIA 
DB20S DD1EG DF5DP DL1YDD DL8NCI DF3LZ DL6KG DL1SBY 
EA2ARU EA2CLS EA4BPN 
G3YJO G4WFQ G8NOB GOK8KA GOMJW G3RUH G4AXC G8TZI G3PIJA 
HB9BOM 
I2KBD I3RUF IV3IBX I6CGE 
JA6FTL JRIEDE JRIING JA10GZ JA1QHQ JH1ITWZ 
KF4WQ K8YAH K7PYK K8IRC 
WC8J WA2LQQ W3QNS WB6YMH WDOE W7KRC W9FMW WBOKSL WA9FMQ WD3Q W3GYJI 
N4HY NK6K N6HBB N5AHD NSBF N3FKV 
LU8DYF 
OH2SN OH2YU 
ON6UG ON5PV ONAKVI 
PE1CHL PA3DVG PELHML PELDNA 
SM5BVF SMOTER 
SV1IT SV3KH 
UA3CR RK3KP 
VK2BKQ VK3DTO VK5AGR VK7ZBX VK6BMD VK6VV VK5HI VK2XLG VK7ZBX VK3DFI VK2AIT 
YNAIUNI 
ZL1AOX ZLITRE ZL1TIK 
KEKKKKKKKKKKKKKKKKKKKKKKKKK KKK KKKKKKKKKKKKKKKKE 


*U0-14 USERS INFO (59 entries Mar.10) 


CALL ! name ! MODEM ! ANT dwnlnk ! RX dwnlnk ! ANT trak ! uplnkPWR ! 
! HM-BBS! TNC ! ANT uplnk ! TX uplnk ! Freq trak! CPU remarksx 
DB20S ! Peter ! G3RUH ! 2x20 XY Maspro! TS-811E ! OSCAR-ST ! <50W ! 


! DKOMAV! TNC2S ! 2x12 XY Maspro! TS-700G Cee ! AT286 16MHz! 


DD1EG ! Det ! G3RUH ! 2x20 XY Maspro! IC-471H ! AMSAT-DL ! <25W ! 
! DBOIZ 1 TNC-2 ! 2x12 XY ! FT-225RD ees ! V-20 8MHz ! 
DF3LZ ! Roland! G3RUH ! 2x19 XY ! C500 ! KCT ! 10W ! 
! DBOOQ ! TNC2C ! 2x12 XY ! TS-700 ie ! AT386/387sx! 
DF5DP ! Bert ! G3RUH ! 2x20 XY Maspro! FT726R ! KCT Pos ! 
! DBOIZ ! TNC2A ! 2x12 XY ! IC-475H Ive ! AT386 33M ! 
DL1YDD ! Hart ! G3RUH ! 2x7 3M BOOM ! FT-780R+AMP ! HB TSR ! 100W ! 
! DBOIZ ! TNC2C ! 2x16 3M BOOM ! FT-480R ts !386/387 33MHz! 
DLISBY ! Axel ! G3RUH ! 2x12 XY RHCP ! IC-275 ! MANUAL ! 100W ! 
Ls ! TNC2C ! 2x20 XY RHCP ! IC-475 i= ! AT 12MHz. ! 
DL6KG ! Hans ! G3RUH ! 4x12 ele.horiz! FT-726R ! MirageMTI! <25W ! 
! DBOIE ! TNC-2 ! 2x9 wle XY ! TS-711E ! MANUAL ! AT286 16MHz! 

DL8NCI ! Matt ! G3RUH ! 17 ele vert. ! FT-726R ! MANUAL ! 10/100W Ix 
! DBOGE ! TNC-2 ! 7 ele vert. ! FT-726R ! MANUAL ! 80286 ! 
EA2ARU ! JABI ! G3RUH ! 2x19 XY TONNA ! TS-790S ! KCT ! 45W ! 
! EA2RCG! TNC-2 ! 2x14 XY TONNA ! TS-790S ! - ! AT286 12MHz! 
EA2CLS/! Tom ! G3RUH ! KLM 435-40CX ! TS-790A ! KCT/ ! 45W ! 
kb7hta! EA2CDN! PK-88 ! KLM 2M-22C ! TS-790A Vs ! AT386 33MHz! 
EA4BPN ! Rafael! NB-96 ! 5/8+5/8 vert. ! TR-851E I se ! 25W ! 
! EA4URE! TNC-2 ! 19ele Hor. ! TS-711E Vos ! AT286 16MHz! 
G4AXC  ! Peter ! G3RUH ! 10 ele XY ! FT-736 ! MANUAL ! 25W ! 
! PLYBBS! TINY2 ! 10t Helix ! FT-736 ! MANUAL ! 286 ! 
G4WFQ ! Dave ! G3RUH ! MBM88EL ! FT736R ! MANUAL ! 25W ! 
! GB7DDX! TNC220! KLM14C ! FT736R ! MANUAL ! PC286 8MHz.! 
G8TZJ ! Andrew! G3RUH ! 17 el XY RHCP ! IC-471E ! HB VIC-20! 60W ! 
! GB7FCI! TINY2 ! 6 el XY RHCP ! IC-211E ! HB AFC ! 8086 8MHz ! 
I3RUF ! GINO ! G3RUH ! 1x21 orriz ! TS-790E ! KCT ! 50W ! 
! I3YPJ ! TNC200! 1x16 orriz ! TS-790E Les ! 386/387 33M! 
I6CGE ! Alfio ! G3RUH ! 2x17+17 ele ! FT-736 ! KCT ! <80W ! 
! I6CGE !MFJ1270! 10+10 ele ! TS-790 ! AUTO ! 286 21MHz ! 
IV3IBX ! FULVIO! G3RUH ! 2x19 XY ! TS-790E ! KCT ! 50W ! 
! IV3PFF! TNC2 ! 2x9 XY ! TS-790S Ise ! 386/287 25M! 
JA10GZ ! Akira ! G3RUH ! 2x19 XY ! FT-780 ! KCT ! 30W ! 
! JL1ZIJ! TNC-2 ! 12 XY ! TR-9000+amp ! MANUAL ! 5530z-SX ! 
JA1QHQ ! Ehara ! G3RUH ! FOFT 19 XY*2 ! IC-371 ! MANUAL ! 4ow ! 
! JL1ZIJ! TNC200! FOFT 9 XY ! IC-251+amp ! MANUAL ! Dynabook ! 
JH1TWZ ! nojyu ! G3RUH ! 2x25 vert ! FT-736 ! MANUAL ! 50W ! 
! JLAZIJ!TNC-20H! 2x12 vert ! FT-736 ! MANUAL !DynaBook (XT) ! 
JRIEDE ! Kohjin! NB96 ! - ! TS-790S ! KCT/IT1.0! 50W ! 
! JL4ZIJ! TINY2 ! - ! TS-790S ! hb AFC ! 386 ! 

JA6FTL ! sueo ! NB96 ! 19 ele XY ! TS-790S ! KCT/IT1.0! 50W Ix 
! JA6FTL!mPOWER2! 12 ele XY ! TS-790S+amp ! hb AFC ! 5530z-SX16M! 
K7PYK ! Wes !PacComm! 2xKLM435-40CX ! FT-736R ! KCT/QT ! 125W ! 
! K7PYK ! TNC-2 ! 2xKLM2M-22C ! FT-736R ! KCTune/QT! 386&286 ! 
K8IRC ! BART ! NB-96 ! 40ele KLM ! FT-736 ! KCT ! 25W ! 
! KAOREW! TINY2 ! 20ele Cir. ! FT-736 ! KCT-tuner! XT 10MHz ! 
K8YAH ! RON ! NB96 ! 6 ele HORZ ! IC-475A ! MANUAL ! 25/200 ! 
! W8CQK ! TNC200! 4 ele VERT ! IC275A+amp ! MANUAL ! TURBO XT ! 


OH2SN ! Pate ! G3RUH ! 19 ele XY ! IC-490E ! Auto ! 150W ! 
! OH2RBI! TNC2C ! 2x9 ele. HOR. ! IC-251/Mutek! Auto dplr! 386 Ix 
OH2YU ! Sirpo ! G3RUH ! 2x17 XY RHCP ! FT-736R ! Auto PC ! 20W ! 
! OH2RBA! TNC-2 ! 2x10 XY RHCP ! FT-736R ! Manual ! 386sx 16MHz! 
ON4KVI !RENAULD! G3RUH ! 17ele XY ! TS811 ! MANUAL ! 100W ! 
! ON7RC ! TNC2S ! 9ele XY ! TS711 ! MANUAL ! PCXT 8MHz. ! 
ON5PV ! PHIL ! G3RUH ! 17ele V-H ! FT-726R ! MANUAL ! 4ow ! 
! ON7RC ! TNC2S ! 6ele V-H ! TM221E ! MANUAL ! 286 16MHz ! 
ON6UG ! Freddy! G3RUH ! 2M Dish ! FT-736R ! HB Auto ! 80W ! 
! ON7RC ! TNC2C ! 9 ele XY ! FT-736R is ! 386SX 16MHz! 
PA3DVG ! AREND ! G3RUH ! 2x17 CD HOR. ! FT-736R ! KCT ! 100W ! 
! PI8JYL! PK87 ! 2x15 CD HOR. ! FT-736R ! KCT ! 386 25MHz ! 
PE1CHL ! Rob ! G3RUH ! 2x15 XY RHCP ! FT-712RH ! fixed elv! 45W Ix 
! PI8UTR! HB ! 2x6 XY RHCP ! FT-212RH Iie ! Atari520ST ! 
PETHML ! Hendrik!G3RUH ! TURNSTYLE ! FT-780 ! NONE ! 12W Ix 
! PI8ZAA!SCC8530! VERTICAL ! FT-480 ! NONE ! 8MHz PC ! 
PE1DNA ! Joop ! G3RUH ! 19ele Yagi ! IC-475 !MANUAL(IT)! - ! 
tos ! none ! 15ele Yagi ! IC-275 Voss ! AT clone Ix 
RK3KP !ClubSTn! NB96 ! 2x20 XY Maspro! FT-736R ! KCT ! - Ix 
! RK3KP ! TINY2 ! 2x12 XY ! FT-736 ! MANUAL ! 286 ! 
SMOTER ! BRUCE ! G3RUH ! 4x14 SKEWED CP! TX790A ! HB 8052 ! 45W ! 
! SMOETV! TINY2 ! 2x9 SKEWED CP! TX790A ! HB AFC ! COMPAQ286  ! 
SM5BVF ! HENLY ! G3RUH ! 2x13 skewed ! IC-475 ! KCT ! 50W ! 
! SMOETV! TNC200! 2x6 skewed ! IC-275 ! HB ! 386 16MHz ! 
SV1IT ! Kostas! G3RUH ! 9ele vertical ! TR851 ! MANUAL ! 25W ! 
! UOSAT3! TNC-2 ! 19ele vertical! TR751 ! MANUAL !COMPAQLTE386! 
SV3KH ! Nick ! NB96 ! 2x22ele K1FO ! IC-475 ! MANUAL ! 25W ! 
! SV8RV !MFJ1270! 2x9ele TONA ! IC-275 Poe ! 386sx 16MHz! 
UA3CR ! Leo ! G3RUH ! 9ele FOFT ! FT-736 ! Fixed He is ! 
! RK3KP ! TNC2 ! Helix 10T ! FT-736 ! MANUAL ! XT ! 
VK2AIT ! Geoff ! G3RUH ! 15 ele HOR ! FT-780R ! MANUAL ! <50W ! 
! VK2XY ! TINY2 ! 12 ele HOR ! FT-480R ! MANUAL ! 386 33MHz ! 
VK3CFI/! Maggie! G3RUH ! Maspro ! IC-251A ss os Ix 
VK3DFI! VK3JAV!mPOWER2! Maspro ! IC-471H ! - ! T3100E ! 
VK3DTO ! Andy ! G3RUH ! 2x12 XY 18ver ! TS-711A Wh Wee ! 
! - !mPOWER2! 2x11 XY ! TS811,IC490A! - ! - ! 
VK5AGR ! Graham! G3RUH ! 2x20 XY Maspro! IC-271A ! KCT/IT1.0! 25W ! 
! VK5WI ! PK87 ! 2x12 XY ! IC-471A ! MANUAL ! AT286 12MHz! 
VK5HI ! Colin ! G3RUH ! 2x9 ele KLM ! TS-700A ! MANUAL ! 10/100W ! 
! - ! TINY2 ! 2x7 ele KLM ! TS-811A ! MANUAL ! 386sx 20MHz! 
VK6BMD ! Bruce ! G3RUH ! 2x19 el vert ! IC-471H ! MANUAL ! 25W ! 
! VK6BBS! FRASH ! 1x17 el vert ! IC-290H ! MANUAL ! XT 8MHz. ! 
VK6VV ! Arnold! G3RUH ! 16T Helical ! TS-790A ! MANUAL ! 45W ! 
! VK6BBS!PAD-205! 14 ele Vert ! TS-790A !JA6FTL AFC! AT286 16MHz! 
VK7ZBX !Richard! G3RUH ! 16T Helix RHC ! FT-736R ! MANUAL ! 25W ! 
! VK7GL ! PK-88 ! 10 XY RHC ! FT-736R ! MANUAL ! 286 20MHz. ! 
W3GYJ_ ! ROD ! NB96 ! KLM44CX ! FT-736R ! KCT/QT4.0! 25W ! 
i= ! TINY2 ! CR144-20 ! FT-736R ! KCT-Tuner! 386 25MHz. ! 


W7KRC ! Wally ! NB96- ! KLM44CX ! FT-726R ! XCT/xt ! 25W ! 
! K7ZTM ! TINY2 ! KLM22C ! FT-726R ! MANUAL ! Laptop12MHz! 

WOFMW ! Jack ! NB96 ! 2xKLM 40CX ! IC-475A ! Graftrak ! 100W ! 
! KAOLQM! TNC200! 2xKLM 22C ! IC-274A+amp ! 2xKCT ! 286 16MHz ! 

WA2LQQ ! Rip ! NB96 ! KLM435-40CX ! TS-790A ! KCT/GT ! 45wW ! 
! WA2SNA! TNC-2 ! KLM2M-22C ! TS-790A ! KCTune/GT! 286 12Mhz. ! 

WA9FMQ ! Gary ! NB96 ! KLM-14c ! TS-790 ! KCT/QT4.0! - ! 
! - !mPOWER2! KLM-22c ! TS-790 ! KCT Tuner! Zeos386sx ! 

WB6MPQ ! Al ! NB-96 ! KLM-40C ! FT-736 ! MANUAL ! 50wW ! 
!NN2Z.NJ! PK232 ! KLM-22C ! FT-736 ! MANUAL ! 386 2QMHz ! 

WC83I ! Rich ! G3RUH ! 2Qele RH-XY ! ICOM 471H ! HB + IT ! - ! 
DS ! 1270B ! 40ele XY ! ICOM 275H ! - ! 286 16MHz ! 

WD3Q ! Eric ! NB96 ! KLM-14c ! TS-790 ! KCT Vhs ! 
Vo es !'mPOWER2! KLM-22C ! TS-790 ! KCT-tuner! Zeos386sx ! 

ZL1A0X ! Ian ! G3RUH ! 15T HELIX RHC ! IC-475H ! MANUAL ! <75W ! 
! ZL1AB !MFI1270! KLM22C,5/8COLI! IC-275H ! MANUAL ! XT 1OMHz ! 

ZLITRE ! Mark ! G3RUH ! KLM40CX ! TS-811A ! MANUAL ! 25W ! 
! ZL1AB !MFI1270! KLM22C ! TS-711A ! MANUAL ! 386 26MHz ! 

Remarks 

DL8NCI : developing own £tl0/bdcast s/w. 

JA6FTL : AFC for 790/736 document is uploaded to this board. 

PE1CHL : developing PACSAT s/w for Atari ST&PC,TCP/IP PEICHL version with FTLO 

PE1HML : Using NET TCP/IP with £tl0 by PE1CHL 

PE1DNA : No TNC's 2x0PtoPcScc card by PAOHZP (4 8530s) 

RK3KP : Amsat-U-Sputnik.Club Stn of Center of Science & Technology for Youth 

VK3CFI : CFI:Maggie, DFI:Lou 


WD3Q/WA9FMQ : VITA station in Rosslyn,VA,Washington.DC 

OH2SN : rx freq controled by 1khz steps with freq.calclat. tracking program 
PLEASE give me your comment about this format and send your station 

information with above form via UO-14/A0-16/FO-20.IF you have general remarks, 

Pse inform me within one line. 


73S SUEO ASATO JAG6FTL @ja6ftl.jnet6.jpn.asia 


Reposted (without permission ;-) by: 


N5KNX Internet: jpd@usl.edu 

Ham packet: n5knx@k5arh 

US Mail: PO Box 42770 Lafayette, LA 
Tel. 318-231-6417 U.S.A. 


-- James Dugal, 
Associate Director 
Computing Center 
University of Southwestern LA. 


70504 


Date: 15 Mar 91 02:50:40 GMT 

From: swrinde!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!matt.ksu.ksu.edu! 
steve@ucsd.edu 

Subject: Hierarchical Forwarding pounds (4) 

To: packet-radio@ucsd.edu 


While using hierarchical addressing on the packet network, what is 
the use of the pound (#) in the address. An example would be: 


KBOAGD @ KOVAY.#NEKS.KS.USA.NA 


I realize that #NEKS means North East Kansas, but what is the # 
for? A flyback from the days of early sub-netting? 


-Steve Schallehn, KBOAGD 
Kansas State University 


Date: 18 Mar 91 15:23:41 GMT 

From: mcsun!ukc!axion! kitkat!blloyd@uunet.uu.net 
Subject: Hierarchical Forwarding pounds (4) 

To: packet-radio@ucsd.edu 


> 

> The main reason for having the # before the second field is to eliminate any 

> problem which may arise from having a local hierarchical address which is 

> the same as a country or continent designator. If, for example, you had a 

> local address of NA (for Northern Australia, say), then the BBS would try to 
ANNAN 

> send the message to North America, as that is what NA is supposed to be. 

> 

That should have been ‘might', rather than ‘would', depending on how the 

forwarding file was set up. The important thing is that the BBS would have 

to know the difference between NA meaning Northern Australia and NA meaning 

North America. 

Brian 


Date: 15 Mar 91 05:16:57 GMT 

From: brian@ucsd.edu 

Subject: Hierarchical Forwarding pounds (4) 
To: packet-radio@ucsd.edu 


In article <1991Mar15.025040.16086@maverick.ksu.ksu.edu> steve@matt.ksu.ksu.edu 
(Steve Schallehn) writes: 
>While using hierarchical addressing on the packet network, what is 


>the use of the pound (4#) in the address. An example would be: 
>KBOAGD @ KOVAY.#NEKS.KS.USA.NA 


The # (sharp, octothorp, hash, pound, etc ad nauseum) means that the 
"regional" name following is a non-standardized one, as if the others 
were more standardized. In particular, it means that it's a more 
localized routing indicator than ones that don't have the # in front of 
them, and can be skipped without error if the station attempting to route 
doesn't know what it means. (I.e., if you don't know what #NEKS means, 

you may unhesitatingly skip over it and attempt to route at the KS.USA.NA) 
(Note that the TELLUS.SOL.MW is implied in this address and need not be 
supplied.) 


Do not confuse these with the Internet hierarchical domains. They don't 
have any thing to do with the DNS, despite their identical format. Grr. 
- Brian 


Date: 19 Mar 91 10:44:24 GMT 

From: ucselx!bionet!apple!mips!spool.mu.edu!munnari.oz.au!manuel! 
csc.canberra.edu.au! echo! skcm@ucsd.edu 

Subject: Hierarchical Forwarding pounds (4) 

To: packet-radio@ucsd.edu 


In <1991Mar18.150624.23335@axion.bt.co.uk> blloyd@axion.bt.co.uk (Brian Lloyd) 
writes: 


>The idea of scanning from left to right is to find the most direct route to 
>the destination. If I was to forward a message to you, the BBS would perform 
>the following steps : 

>If, on the other hand, I had a direct link to VK6BBS I would forward the 
>message there, rather than to Australia, as VK6BBS is much closer to you 
>Australia in general. 


Hang on. It would be stupid to route only on the first match. I can't believe 
Internet domain routers operate by only matching the first match from right to 
left! 


What you are saying is that EVERY segment of an address must be unique 
world wide. This, obviously, won't work! The higher levels in the address 


MUST be taken into consideration when making a match. 


Carl. 


Date: 19 Mar 91 02:50:20 GMT 


From: munnari.oz.au! yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au! 
snap.adelaide.edu.au@THEORY.TN.CORNELL. EDU 

Subject: Hierarchical Forwarding pounds (4) 

To: packet-radio@ucsd.edu 


Organization: Adelaide University 
NNTP-Posting-Host: snap.adelaide.edu.au 


Just a note about the H-addressing. 


The new AA4RE v2.11 BBS software DOES now search like the internet 
style. Eg if you have an address of, 


VK5ZWI@VK5TTY .#SA.AUS.OC 
the AA4RE BBS can be set to search for, 


VK5TTY .#SA. AUS .OC 
HSA. AUS .OC 

AUS .OC 

Oc 


The first one that matches is the one that the mail will go to. 


This means the # is no longer required. BUT I wouldnt go suggesting 
it be dropped because there are still many BBS systems that dont 
search that way. 


Cheers de Grant VK5ZWI 


Grant Willis (VK5ZWI) - Adelaide University, South Australia - 
xx 2nd/3rd Year Electrical Engineering Student xx 
Packet Radio: VK5ZWI@VK5TTY .4#SA.AUS.OC AmPR TCP/IP: [44.136.171.11] 
AARNet/Internet1: e2grwill@snap.adelaide.edu.au 
ACSnet/Internet2: e2grwill@snap.ua.oz.au 
Disclaimer: What I write is mine. The Uni has nothing to do with it! 


Date: 18 Mar 91 15:06:24 GMT 

From: mcsun!ukc!axion!kitkat!blloyd@uunet.uu.net 
Subject: Hierarchical Forwarding pounds (4) 

To: packet-radio@ucsd.edu 


Date: 18 Mar 91 21:52:39 GMT 

From: swrinde!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu! hpa@ucsd.edu 
Subject: Hierarchical Forwarding pounds (4) 

To: packet-radio@ucsd.edu 


In article <1991Mar18 .150624.23335@axion.bt.co.uk> blloyd@zaphod.axion.bt.co.uk 
writes: 

>The idea of scanning from left to right is to find the most direct route to 
>the destination. If I was to forward a message to you, the BBS would perform 
>the following steps : 

> 

>Do I know where VK6ZJM is? 

>No - do I know where VK6BBS is? 

>No - do I know where #WA is? 

>No - do I know where AUS is? 

>Yes - forward the message in that direction. 


In proper domain-style addressing, a la the Internet, this would rather be: 


Do I know where VK6ZIJM.WA.AUS is? No 
Do I know where WA.AUS is? No 
Do I know where AUS is? Yes 


Forward in direction AUS 


Note that the complete tail is a part of the address. Thus, VK6ZJM.WA.AUS 
could not be confused with, for example WOBBS.WA.US.NA; if my 
(non-existent) system N9OITP.IL.US.NA connected it would try: 


WOBBS.WA.US.NA Not found VK6ZIM.WA.AUS Not found 
WA.US.NA Found -> forward WA.AUS Not found 
AUS Found -> forward 


See how easy it becomes? 


73 de N9ITP U R 599+9600 BPS KN + @ 
hpa = H. Peter Anvin (in case you wondered) * Heja Sverige! 
INTERNET: hpa@casbah.acns.nwu.edu FIDONET: 1:115/989.4 
HAM RADIO: N9ITP, SM4TKN RBBSNET: 8:970/101.4 


Date: 21 Mar 91 17:07:46 GMT 

From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!munnari.oz.au!uniwa! 
cc.curtin.edu.au!nmurrayr@ucsd.edu 

Subject: Hierarchical Forwarding pounds (4) 

To: packet-radio@ucsd.edu 


In article <1991Mar20.110655.23351@axion.bt.co.uk>, blloyd@axion.bt.co.uk (Brian 
Lloyd) writes: 

The problem comes when we 

comes across a sub-field which is not unique (eg #WA could be Western 
Australia or the Watsui province of Japan). The BBS somehow needs to know 
that there is a #WA in Australia and another one in Japan, and at present I 
don't think that's possible. What needs to be added, therefore, is some way 

of allowing the BBS to forward to #WA.AUS or #WA.JAP 


VV VV VV 


This is the point I was trying to make in my original post. There IS such 
a way, without adding anything. If you scan from right to left, with all fields 
significant, then there's no ambiguity. To use your example, #WA.AUS is 
obviously not the same as #WA.JAP, and any software that thinks it is clearly 
brain-damaged. It's like telling someone that he can't call himself 
"John Smith" because there's already a "John Jones" somewhere else in the 
world, regardless of the fact that they're bound to have different higher-order 
addresses (ie one lives in Sydney and the other lives in Oslo). 


Internet: Murray_RJ@cc.curtin.edu.au "You can lead a horse to 
ACSnet: Murray _RJ@cc.cut.oz.au water, but if you can 
Bitnet: Murray_RJ%cc.curtin.edu.au@cunyvm.bitnet get him to float on his 
UUCP : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ back you've really got 
Amateur Packet Radio: VK6ZJM@VK6BBS.#HWA.AUS.OC something" 
TCP/IP: 44.136.204.14, 44.136.204.19 -- Murphy's Law I 


Date: 16 Mar 91 20:25:48 GMT 

From: usc!apple!bionet!hayes.ims.alaska.edu!acad3.alaska.edu!ifjrs@ucsd.edu 
Subject: Hierarchical Forwarding pounds (4) 

To: packet-radio@ucsd.edu 


In article <1991Mar15.025040.16086@maverick.ksu.ksu.edu>, steve@matt.ksu.ksu.edu 
(Steve Schallehn) writes... 

>While using hierarchical addressing on the packet network, what is 
>the use of the pound (4#) in the address. An example would be: 

> 

>KBOAGD @ KOVAY.#NEKS.KS.USA.NA 

> 

>I realize that #NEKS means North East Kansas, but what is the # 
>for? A flyback from the days of early sub-netting? 

> 

This is an excerpt from documentation provided with AA4RE's BB 


bulletin board program: 


"WORLI, VE3GYQ, and N6VV have devised a scheme called hierarchical 
addressing. Here's their description of their idea: 


(stuff deleted) 


"AS an example, say that we send something to WORLI @ WORLI.CA.USA.NA, 
and that the only entries that we have in the forward file are for 

CA. That match would be sufficient to allow the message to be forwarded. 
If WORLI were found, that entry would take precedence (because 

it is more left in the field than CA) and would of course also 

ensure delivery. The best way to look at it is 'WORLI AT WORLI 

which is in CA which is in USA which is in NA'. So far so good. 


But the Japanese network wants to use area routing numbers. For 
example, JA1ABC.42.JPN.AS ... and everyone says, ‘So what, let 
them!' Of course, that is very mature of all of us, but the trouble 
is that the 42 in that string may also match wild-card ZIP codes 
that some folks keep in their forward file, such as 42x. The 
solution we propose is to use an agreed upon key character for 
designators below the state and province level, and we recommend 

the octothorpe, ‘#'. 


So now the above address would be JA1ABC @ JA1KSO.#42.J3PN.AS ..." 
(etc.) 

Hope that explains a little more fully the reasoning ... 

John 


>-Steve Schallehn, KBOAGD 
> Kansas State University 


John Stannard 


ifjrs@acad3.fai.alaska.edu BITNET: IFJRS@ALASKA 
KL7JL@KL7JL.AK.USA.NA k17jl.ampr.org [44.22.0.1] 
"God is the Answer!" "Oh?? ... er, ... What was the Question?" 


Date: 21 Mar 91 01:49:06 GMT 


From: sdd.hp.com!spool.mu.edu!munnari.oz.au!manuel!csc.canberra.edu.au!echo! 
skcm@ucsd.edu 

Subject: Hierarchical Forwarding pounds (4) 

To: packet-radio@ucsd.edu 


In <1991Mar20.110655.23351@axion.bt.co.uk> blloyd@axion.bt.co.uk (Brian Lloyd) 
writes: 


>comes across a sub-field which is not unique (eg #HWA could be Western 
>Australia or the Watsui province of Japan). The BBS somehow needs to know 
>that there is a #WA in Australia and another one in Japan, and at present I 


Precisly. The WHOLE address needs to be taken into consideration when 
routing. You cannot route to just "#HWA". You must route to "#WA.AUS.OC". 


>> VK6ZIJM) should ONLY be considered for routing purposes if it is shown as part 
>I think that when someone moves the first person they tell (in the packet 
>world) is the SYSOP of their local BBS, otherwise that BBS is going to keep 
>trying to forward mail to them when they're not there. Being able to forward 
>on the TO field is often very useful - remote SYSOPs often like to have mail 
>addressed to SYSOP forwarded on to them, for example. 


Forwarding on the TO field shouldn't be enabled. The ONLY thing the TO 

field should be used for is allowing the destination station (named in the TO) 
to read his private mail. It certainly shouldn't be used for forwarding. 

Most (if not all) programs allow remapping of addresses. If your remote 
SYSOP (mentioned above) wanted to get his bulletins then they should be 
remapped to SYSOP@<his BBS>. 


Maybe things are different in the UK but here in Canberra I don't try to 
forward mail to individual users. They log on to my BBS to read it. I 
have 2 users who run PMSs who get mail forwarded and I have asked them to 
detail their heirarchical addresses as; 

(for example) 

vkimc@vkimce.vk1lkcm.act.aus.oc 

and no other BBS except me has to have routing information for them. 

(I also remap vkimc@vkikcm to vkimc@vkimc.vkikcm.act.aus.oc as few 
amateurs understand heirarchical addressing. :-( ) 


The TO field on Bulletins is another story. :-( It shouldn't be there 
at all. 


Carl. 

vkikcm@vkikcm.act.aus.oc 
skcm@ise.canberra.edu.au 
3:620/241.7 

[44.136.0.5][14][16] PC/BBS/Xenix 


Date: 19 Mar 91 18:21:01 GMT 

From: swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!bloom-beacon! 
eru!hagbard!sunic!mcsun!ukc!vision!mgc!dave@ucsd.edu 

Subject: Hierarchical Forwarding pounds (4) 

To: packet-radio@ucsd.edu 


In article <1991Mar18.150624 .23335@axion.bt.co.uk> blloyd@zaphod.axion.bt.co.uk 
writes: 

>From article <7492.27e484b1@cc.curtin.edu.au>, by Murray_RJ@cc.curtin.edu.au (Ron 
Murray) : 

>> 

>> 1. The whole hierarchical forwarding process as implemented is a kludge (like 
>> half of the rest of packet's "protocols"): why in hell should it scan left 
>> to right when it makes more sense to scan right to left? 

> 

>The idea of scanning from left to right is to find the most direct route to 
>the destination. If I was to forward a message to you, the BBS would perform 
>the following steps : 

> 

>Do I know where VK6ZJM is? 

>No - do I know where VK6BBS is? 

>No - do I know where #WA is? 

>No - do I know where AUS is? 

>Yes - forward the message in that direction. 

> 


It's equally true to say: 


Do I know where AUS is? Yes - continue; No - warn Sysop 

Do I know where #WA is? Yes - continue; No - forward using AUS 

Do I know where VK6BBS is ? Yes - continue; No - forward using ##WA 
Do I know where VK6ZJM is ? Yes - forward, No - forward using VK6BBS 


So right to left is OK, too...and is much more in line with most other mail 
system algorithms (although that might not count for much!). However, with 
your method, you might get the answer: 


VK6ZIJM - no 
VK6BBS - no 
#WA - yeS...... it's the Watsui province of Japan, so send it there. 


Right to left precedence is required. 


And while I'm pontificating (:-) the left most callsign (in the above examples 
VK6ZIM) should ONLY be considered for routing purposes if it is shown as part 
of the domain segment (eg VK6ZIM.VK6BBS.#WA.AUS). Once the '@' is reached in 


the right to left scan, routing should stop. The reason is this: the originator 
of the message may know that VK6ZJM has moved QTH - routing software wouldn't 
always know this. 


Dave Lockwood dave@mgc.uucp G4CLI@GB7DCC._199.GBR.EU 
Head of Technology ...!uunet!mcsun!ukc!vision!mgc!dave 


MG Computer Systems Ltd, PO Box 50, Doncaster, DN4 5AW +44-302-738770 


Date: 18 Mar 91 01:13:21 GMT 

From: sdd.hp.com!samsung!munnari.oz.au!uniwa! vax7!nmurrayr@ucsd.edu 
Subject: Hierarchical Forwarding pounds (4) 

To: packet-radio@ucsd.edu 


In article <1991Mar16.202548.18162@ims.alaska.edu>, ifjrs@acad3.alaska.edu 
(STANNARD JOHN R) writes: 


(quoting from the AA4RE documentation) 


"AS an example, say that we send something to WORLI @ WORLI.CA.USA.NA, 
and that the only entries that we have in the forward file are for 

CA. That match would be sufficient to allow the message to be forwarded. 
If WORLI were found, that entry would take precedence (because 

it is more left in the field than CA) and would of course also 

ensure delivery. The best way to look at it is 'WORLI AT WORLI 

which is in CA which is in USA which is in NA'. So far so good. 


But the Japanese network wants to use area routing numbers. For 
example, JA1ABC.42.JPN.AS ... and everyone says, ‘So what, let 
them!' Of course, that is very mature of all of us, but the trouble 
is that the 42 in that string may also match wild-card ZIP codes 
that some folks keep in their forward file, such as 42x. The 
solution we propose is to use an agreed upon key character for 
designators below the state and province level, and we recommend 

the octothorpe, '#'. 


VVVVVV VV VV VV VV VV VV 


So far, it all seems to make sense (even if about as easy to read as Attila 
the Hun's laundry list). Here in Australia they went a little further... 


If you look at my .sig below, you'll see the #WA between the BBS call and 
the abbreviation for Australia. We were told that this was necessary (rather 
than the much more obvious "WA" for Western Australia) because the hierarchical 
forwarding software would assume that it was the abbreviation for Washington 


state in the US because it scans the address from left to right. This leads me 
to conclude that either: 


1. The whole hierarchical forwarding process as implemented is a kludge (like 
half of the rest of packet's "protocols"): why in hell should it scan left 
to right when it makes more sense to scan right to left? Internet domain 
names are scanned in this fashion. It's a bit like telling someone that he 
can't call himself "John Smith" because there's already a John Smith 
somewhere else. Or worse, that he has to call himself #Fred Bloggs because 
there's a Fred Bloggs in Outer Mongolia. 


or 


2. Someone in Australia mis-read the documentation and decided that this name 
change was necessary. This is probably the more likely. 


Suggestions and corrections welcome. 


.Ron 


Internet: Murray_RJ@cc.curtin.edu.au "You can lead a horse to 
ACSnet: Murray _RJ@cc.cut.oz.au water, but if you can 
Bitnet: Murray_RJ%cc.curtin.edu.au@cunyvm.bitnet get him to float on his 
UUCP : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ back you've really got 
Amateur Packet Radio: VK6ZJIM@VK6BBS.#HWA.AUS.OC something" 
TCP/IP: 44.136.204.14, 44.136.204.19 -- Murphy's Law I 


Date: 20 Mar 91 11:06:55 GMT 

From: gatech!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!axion! kitkat! blloyd@ucsd.edu 
Subject: Hierarchical Forwarding pounds (4) 

To: packet-radio@ucsd.edu 


Date: 20 Mar 91 21:27:34 GMT 

From: swrinde!elroy.jpl.nasa.gov!usc!apple!erc@ucsd.edu 
Subject: How to get email from packet??? 

To: packet-radio@ucsd.edu 


I'm a relative newcomer to the world of packet radio, and am interested 


in getting email via packet. How might this be accomplished? If someone 
could point me to references, books, etc. that might help (something current) 
I'd really appreciate it! 


Ed Carp, N7EKG/6 

Alameda, CA 

Ed Carp N7EKG/6  erc@khijol.UUCP ...uunet! khijol!erc 
Alameda, CA 


Computers HAVE caused a revolution in how much information we 
can safely ignore! --robs@ux1.cso.uiuc.edu (Rob Schaeffer) 


Date: 15 Mar 91 20:06:53 GMT 

From: hpl-opus!hpnmdla!alanb@hplabs.hpl.hp.com 
Subject: Inadvertant "clear screen" 

To: packet-radio@ucsd.edu 


In rec.radio.amateur.packet, andrem@pyrman2.pyramid.com (Andre Molyneux) writes: 


>I've been experiencing an odd problem with my packet station. Basically, 
>my screen gets cleared by the transmissions of other stations. The problem 
...>developed as follows: 


>I understand that I can set the TNC to filter out specific characters that 
>are incompatible with the terminal in use. Obviously ctrl-z is one of them, 
>but I need to find what the other "clear screen" character is. Any idea on 
>how I should go about this? 


The ASCII "formfeed" character (12 decimal) is used as a "clear screen" 
command by many terminals. 


AL N1AL 


Date: 18 Mar 91 19:37:51 GMT 

From: swrinde!zaphod.mps.ohio-state.edu! pacific.mps.ohio-state.edu!linac, 
Subject: Inadvertant "clear screen" 

To: packet-radio@ucsd.edu 


In article <2285@ke4zv.UUCP> gary@ke4zv.UUCP (Gary Coffman) writes: 
>formfeed will be one character you'll want to filter. Most nodes, and 
>all TCP/IP stations transmit some packets in fully binary mode so you 
>will often have characters on your screen in monitor mode that will 


The 1.1.7 tapr firmware (MFJ adds WEFAX and calls it 1.2.7) includes 
a MNONAX25 ON/OFF command, to eliminate tcp/ip, netrom routing, and 
other packets having a PID different from that of AX.25. 


73, 

-- James Dugal, N5KNX Internet: jpd@usl.edu 

Associate Director Ham packet: n5Sknx@k5arh 

Computing Center US Mail: PO Box 42770 Lafayette, LA 70504 


University of Southwestern LA. Tel. 318-231-6417 U.S.A. 


Date: 17 Mar 91 18:45:47 GMT 

From: usc!zaphod.mps.ohio-state.edu! pacific.mps.ohio-state.edu!linac, 
Subject: Inadvertant "clear screen" 

To: packet-radio@ucsd.edu 


In article <148305@pyramid.pyramid.com> andrem@pyrman2.pyramid.com (Andre 
Molyneux) writes: 

>I've been experiencing an odd problem with my packet station. Basically, 
>my screen gets cleared by the transmissions of other stations. The problem 
>developed as follows: 

[deleted] 

>I understand that I can set the TNC to filter out specific characters that 
>are incompatible with the terminal in use. Obviously ctrl-z is one of them, 
>but I need to find what the other "clear screen" character is. Any idea on 
>how I should go about this? (I've asked another packet operator to see if 
>he get's any "unusual" characters from the node in question. He reports 
>that he doesn't see anything out of the ordinary when he connects to this 
>node. ) 


Some TNCs have a filter command that removes all non-printing characters 
from the incoming stream. I don't believe the MFJ 1274 is one of them. 

I think you are limited to 10 characters in your filter list. Certainly 
formfeed will be one character you'll want to filter. Most nodes, and 
all TCP/IP stations transmit some packets in fully binary mode so you 
will often have characters on your screen in monitor mode that will 
cause your terminal to do strange things. You'll need to sit down with 
your terminal book and TNC manual and figure out what to kill. 


Gary KE4ZV 


Date: 14 Mar 91 23:39:46 GMT 
From: pyramid! andrem@hplabs.hpl.hp.com 
Subject: Inadvertant "clear screen" 


To: packet-radio@ucsd.edu 


I've been experiencing an odd problem with my packet station. Basically, 
my screen gets cleared by the transmissions of other stations. The problem 
developed as follows: 


I bought a MFJ 1274 TNC and hooked it up to a XT clone using Procomm. 
Everything ran fine. Decided to free up the PC by getting a dedicated 
terminal for packet. Borrowed a Lee Data (don't remember the model #) 
terminal from a friend, which ran in VT200 emulation mode. Found that 
the screen would get cleared everytime my TNC tried to display a packet 
from a local node (SFO on 145.01 in the SF bay area). I connected to 
this node and found that any option I chose would result in a cleared 
screen. 


I didn't worry about it too much considering that the terminal was a 
loaner. Well, this past weekend I went to the Foothill College swapmeet 
and picked up an old Televideo terminal (TVI 321???). Fired it up and 
found that it too would get its screen cleared by the same node. In 
addition, I found that the character used to indicate the end of a 
message on mailboxes (ctrl-z), also clears the screen of the Televideo 
(ctrl-z didn't bother the Lee Data). 


I understand that I can set the TNC to filter out specific characters that 
are incompatible with the terminal in use. Obviously ctrl-z is one of them, 
but I need to find what the other "clear screen" character is. Any idea on 
how I should go about this? (I've asked another packet operator to see if 
he get's any "unusual" characters from the node in question. He reports 
that he doesn't see anything out of the ordinary when he connects to this 
node. ) 


f--------------------------------------------------- f-------------------------- + 
| Andre Molyneux KA7WVV andrem@pyrman2.pyramid.com |*** GENERIC DISCLAIMER xxx| 
f--------------------------------------------------- f-------------------------- + 
| Boree asses PYRAMID TECHNOLOGY CORPORATION |All the usual disclaimers | 
| =a eS Ssie res 1295 Charleston Road |apply although, as far as | 
| -----=====---- Mountain View, California 94043 [I can tell, my employer | 
|-------=======-- (415) 965-7200 |doesn't care what I think! | 
fo--------------------------------------------------- f-------------------------- + 


Date: 20 Mar 91 04:20:39 GMT 

From: uhccux!uhcmtg.phys.hawaii.edu! tony@ames.arpa 
Subject: KA9IQ & mbox BBS forwarding 

To: packet-radio@ucsd.edu 


I need some assistance from any kind soul in mbox message forwarding. 


I'm trying to setup a PC running KA9Q to forward messages to non-TCP/IP 
stations. Suppose I want messages for AH6BW to be forwarded to AH6BW@AH6BW-2 
where AH6BW-2 is a different machine that doesn't handle TCP/IP. 


In my /alias file I have: 
ahébw ah6ébw@ahébw-10 


In my /spool/forward.bbs file I have: 


ah6ébw-10 
ax25 ax1 ah6ébw-10 
ah6ébw 


When the SMTP timer kicks in I get a message about ah6ébw-10 being an unknown 
host (as if it wants to deliver the message via TCP/IP and it fails ona 
hostname lookup). Shouldn't the entry in the forward.bbs file be enough to 
tell NOS that ah6ébw-2 is NOT a TCP/IP station? What am I missing here? 


I'm running the latest version of NOS from thumper. 


Tony 
AH6BW 
tony@uhcmtg. phys. hawaii. edu 


Date: 21 Mar 91 17:13:53 GMT 

From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!munnari.oz.au!uniwa! 
cc.curtin.edu.au!nmurrayr@ucsd.edu 

Subject: KA9Q v910308 problems 

To: packet-radio@ucsd.edu 


When I run KA9Q version 910308 on my XT clone, it works fine on a SLIP link 
to my AT at 9600 baud. If I try an AX25 connect to a non-TCP/IP system, it 
crashes after a few K of data has been received. I don't think it happens 
on a Telnet session over AX25, but I can't test it due to a complete lack of 
other stations here in Perth running TCP/IP (Philistines!). It certainly 
didn't crash the one time I tried a Telnet to it from someone else's computer, 
but I might have been lucky. 

Has anyone else experienced this? 


Internet: Murray_RJ@cc.curtin.edu.au "You can lead a horse to 
ACSnet: Murray _RJ@cc.cut.oz.au water, but if you can 
Bitnet: Murray_RJ%cc.curtin.edu.au@cunyvm.bitnet get him to float on his 
UUCP : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ back you've really got 
Amateur Packet Radio: VK6ZJM@VK6BBS.#HWA.AUS.OC something" 
TCP/IP: 44.136.204.14, 44.136.204.19 -- Murphy's Law I 


Date: 17 Mar 91 00:44:36 GMT 

From: sdd.hp.com! zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!matt.ksu.ksu.edu! 
steve@ucsd.edu 

Subject: KAM dual-mode enhancement 

To: packet-radio@ucsd.edu 


[hopefully there is enough interest to merit this reply] 


A question came over the net a few weeks ago asking if a Kantronics 
KAM could do both VHF packet and HF RTTY operation simultaneously. 


After talking to Karl Medcalf of Kantronics, I have just found out 
that Kantronics is testing new firmware to allow any HF operation and 
VHF packet operation to occur at the same time on a Kantronics KAM. 
With the firmware upgrade and a specialized program running on a PC, 
one could, for example, log into a DX cluster and work RTTY at 

the same time. 


Availability for the upgrade scheduled mid-spring. Pricing for upgrades 
is somewhere around $100. 


-Steve Schallehn, KBOAGD 
Kansas State University 


PS: I am not affiliated with Kantronics. 


Date: 15 Mar 91 18:16:15 GMT 

From: swrinde!zaphod.mps.ohio-state.edu!caen!kuhub.cc.ukans.edu! zeus.unomaha.edu! 
acmnews@ucsd.edu 

Subject: Monthly On-Line Elmers Resource Directory 

To: packet-radio@ucsd.edu 


As part of the multi-pronged strategy of Project SAVE THE BANDWIDTH, I 


will now put out a call for On-Line Elmers. These are people, who by 
virtue of skill and knowledge in an area of expertise in ham radio, 
are willing to field E-mail by readers of the rec.radio.* groups. 


Volunteers need only send me their name, E-mail address, and area of 
expertise. "Generalists" or "Miscellaneous" Elmers are also quite 
welcome. Naturally, the more that volunteer, the more the work is 
distributed. If upon volunteering, you are unable to meet your 
obligations, simply write to me and I will remove your name from the 
list. I could also add that because of "personal committments" or 
"career broadening" you no longer are available to Elmer on a regular 
basis. 


I will be the point-of-contact for this project. I will maintain the 
list, post it to the groups at least monthly, and have the latest copy 
placed in the supplemental archives at ftp.cs.buffalo.edu in 
subdirectory pub/ham-radio. 

Here is the latest version of the list. If you sent me mail and are 
not on it, please resend as it may have been lost on the way or once 
it reached my host. 

73, Paul, KD3FU 


ACMNEWS@zeus.unomaha.edu uunet!unocss!zeus!acmnews 137.48.1.1 


ps67@umail.umd.edu uunet!mimsy!umail!ps67 128.8.10.28 


ON-LINE Elmers Resource Directory (as of 03/15/91) 


Dan Halbert, KB1RT 
QTH is West Newton, MA, near Boston. 


halbert@crl.dec.com 
Building homebrew QRP gear, Advice on simple antennas 
Paul W. Schleck, KD3FU 


acmnews@zeus.unomaha. edu 
ps67@umail.umd.edu 


Miscellaneous, Internet, College Clubs 


Mike Waters AA4SMW/7 
waters@nddsun1.sps.mot.com 


Miscellaneous 


Date: 22 Mar 91 00:42:34 GMT 

From: dog.ee.lbl.gov!ncis.tis.llnl.gov!1l1l1l-winken! uwm.edu!caen!kuhub.cc.ukans.edu! 
zeus.unomaha.edu! acmnews@ucsd. edu 

Subject: Monthly On-Line Elmers Resource Directory 

To: packet-radio@ucsd.edu 


(Note: Although less than a month has gone by, my list of volunteers 
has nearly quadrupled. Also, someone suggested that I add a list 
of suggested areas of expertise. So, here is the latest list...) 


As part of the multi-pronged strategy of Project SAVE THE BANDWIDTH, I 
will be compiling a directory of On-Line Elmers. These are people 
who, by virtue of skill and knowledge in an area of expertise in ham 
radio, are willing to field E-mail by readers of the rec.radio.* 
groups. 


Volunteers need only send me their name, E-mail address, and area of 
expertise. As requested, here is a suggested list of areas of 
expertise that are needed: 


1. Volunteer Examiners 

2. Novice Instructors 

3. DX'ers and Contesters 

4. QRP 

5. Homebrewers 

6. Packet Ops (both AX.25 and TCP/IP) 

7. WHF and Repeaters 

8. OSCAR and other satellites 

9. MARS (Military Affiliate Radio System) 

10. CAP (Civil Air Patrol) 

11. ARES (Amateur Radio Emergency Service) 

12. RACES (Radio Amateur Civil Emergency Service) 
13. Skywarn (Amateur Weather Spotters) 

14. ARRL Field Organization (American Radio Relay League) 


"Generalist" or "Miscellaneous" Elmers are also quite welcome. 


Naturally, the more that volunteer, the more the work is distributed. 

If upon volunteering, you are unable to meet your obligations, simply 

write to me and I will remove your name from the list. I could also 

add that because of "personal committments" or "career broadening" you 
no longer are available to Elmer on a regular basis. 


I will be the point-of-contact for this project. I will maintain the 
list, post it to the groups at least monthly, and have the latest copy 
placed in the supplemental archives at ftp.cs.buffalo.edu in 
subdirectory pub/ham-radio. 

Here is the latest version of the list. If you sent me mail and are 
not on it, please resend as it may have been lost on the way or once 
it reached my host. 

73, Paul, KD3FU 


ACMNEWS@zeus.unomaha.edu uunet!unocss!zeus!acmnews 137.48.1.1 


ps67@umail.umd.edu uunet!mimsy !umail!ps67 128.8.10.28 


ON-LINE Elmers Resource Directory (as of 03/21/91) 


John Brewer WB50AU 
brewer@anarky.enet.dec.com 
Miscellaneous, Wire antennas, 


Dan Halbert, KB1RT 
QTH is West Newton, MA, near Boston. 


halbert@crl.dec.com 

Building homebrew QRP gear, Advice on simple antennas 
R.D. Keys 

Dept. of Crop Science 


NCSU 
Raleigh, NC 27695-7620 


rdkeys@ccvri1.cc.ncsu.edu 

de NA4G, "Boat Anchor Bob", an ol' cw fart ..... 

If I can be of assistance in older equipment, junk-boxing 
your way to hamdom, the cheapskate's approach, let me 


know. 


22 yrs a ham, extra class, mostly cw, mostly boat anchors 
and radio in the traditional sense. 


4Telegraphy has been in my family for almost 100 years!? 
Dave Potter, K1MBO 
potter@think.com 


electronics theory, regulations, antennas and 
transmission lines, operating practices. 


Tony Reeves 

KK6XC 

QTH Beach Area of So. Los Angeles 

Torrance, Redondo Beach, Hermosa Beach, Manhattan beach 
tony@hacgate.scg.hac.com 


Novice training, local VE for Novice-Tech tests, 
General questions 


Paul W. Schleck, KD3FU 


acmnews@zeus.unomaha. edu 
ps67@umail.umd.edu 


Miscellaneous, Internet, College Clubs 
Tom Sefranek WA1RHP 


tcs@ll.mit.edu 


Elmering for the last 20 years. 
Almost all fields, 
Specializing in power supplies, micro-controllers, antennas 


Diana L. Syriac 
Leominster, MA 
dls@genrad.com 
KC1SP 


QSL Bureaus (how to use them) 
Volunteer Examiner Service (how to become one) 


Macintosh Hamstacks 
Civil Air Patrol 


Mike Waters AA4MW/7 


waters@nddsun1.sps.mot.com 


Miscellaneous 
Bob Witte HP Colorado Springs Division 
bobw@col.hp.com P.O. Box 2197 


Phone: (719) 590-3230 Colorado Springs, CO 80901 
Radio: KBOCY 
"All Disclaimers Apply." 


Miscellaneous 


Date: 14 Mar 91 15:24:00 GMT 

From: swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn! boulder! 
bohemia! £510.n5000.z200.METRONET .ORG! Gary .Box@ucsd.edu 

Subject: New packet user 

To: packet-radio@ucsd.edu 


Hi Clay and welcome to Ham Radio and Packet. I run packet with 


little more than a terminal program on an old CPM machine and it 
works fine. One thing you will need is some local help for finding 
your local BBS on packet; equipment set up; etc. Thats a little 
tough to do here. Once on the air, you can connect to the local BBS 
and send messages all over the world. Most BBS's have a help file 
that will describe the commands. While connected to any other packet 
station, or even to your own mailbox, your computer works as a 
terminal, so I would n't worry about operating system. Just have a 
terminal emulator program available. You can work up to a dedicated 
package like LanLink (which is for DOS) later. 

By the way, when you get running send me a note. My call is NOJCG 
and my home BBS is WAOCQG. You would address a message to me at 
NOJCG @ WAOCQG. I think you'l like packet. I QSO with England, 
Greece and Israel regularly with it. 


* Origin: The Computer Lab (200:5000/510) 


Gary Box - via MetroNet node 200:5000/301 
The Bohemia BBS System, Boulder Colorado (303)449-8946 
UUCP: Gary.Box@£510.n5000.z200.METRONET .ORG 

or: ...!boulder!bohemia.METRONET.ORG!510!Gary.Box 


Date: 21 Mar 91 21:24:28 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: No Subject 

To: packet-radio@ucsd.edu 


Date: 13 Mar 91 22:08:24 GMT 

From: swrinde!zaphod.mps.ohio-state.edu!usc!apple!bionet!hayes.ims.alaska.edu! 
acad3.alaska.edu!ifjrs@ucsd.edu 

Subject: Packet BBS SID and personal mbox reverse forward 

To: packet-radio@ucsd.edu 


In article <3091@oucsace.cs.QOHIOU.EDU>, farrar@oucsace.cs.ohiou.edu (J. Craig 
Farrar) writes... 

>Problem: Home BBS (MBL) will forward to personal mailbox in my TNC, but the TNC 
>will not respond to the reverse forward poll when it sees it. 

> 

(Stuff deleted) 


> 

>The MBL board is a busy one and successfully forwards and reverse forwards 
>with several neighboring boards. The problem with the TNC mailboxes seems 

>to be that they don't have a '$' in their SID. That is reasonable since they 
>are intended for private mail forwarding and not the flood forwarding that 
>needs BID checking. However, it causes the reverse forwarding to fail because 
>the full-service BBS stations seem to require it. 

> 

>Checking with the sysop of the MBL board we learn that this is a built-in 
>feature and can't be changed. Is this really true? It would really be nice 
>to have reverse forwarding work as it has been advertised, but we seem to have 
>an impasse. Do any of you in the net know a solution? 

> 

A user here in Alaska has a KAM with the same problem--he adds the 

SID _with_ the '$' in his "connect" text msg--it seems to work 

quite well. Hope this works for you in _your_ situation. 


73, John 


>J. Craig Farrar farrar@oucsace.cs.ohiou.edu W8UKE@KA8DRR.OH.USA.NA 
>Ohio University, Athens, Ohio 


John Stannard 


ifjrs@acad3.fai.alaska.edu BITNET: IFJRS@ALASKA 
KL7JL@KL7IL.AK.USA.NA k17jl.ampr.org [44.22.0.1] 
"God is the Answer!" "Oh?? ... er, ... What was the Question?" 


Date: 20 Mar 91 20:27:21 GMT 

From: newstop!eastapps!Sun.COM! kerskine@sun.com 
Subject: PK-88 Pinouts 

To: packet-radio@ucsd.edu 


I bought a PK-88 a few months ago and am now ready to use it, 
but I seem to have misplaced the manual. Can anyone tell me 
the pinouts on the 8 pin tx/re connector? 


Thanks....Keith Erskine - KAZLRHO 


ps: I'm connecting this to an old Yaesu FT-22R 2M all-band. Any 
special considerations I should know about? - thx ke 


Date: 21 Mar 91 17:34:42 GMT 

From: sdd.hp.com! zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att! 
pacbell.com! tandem! netcom! edg@ucsd.edu 

Subject: PK-88 Pinouts 

To: packet-radio@ucsd.edu 


In article <4984@eastapps.East.Sun.COM> kerskine@Sun.COM (Keith Exskine - Sun 
Technical Marketing - Boston) writes: 

>I bought a PK-88 a few months ago and am now ready to use it, 

>but I seem to have misplaced the manual. Can anyone tell me 

>the pinouts on the 8 pin tx/re connector? 


Ground Brown 

Mic AudioWhite 

Push-To-Talk Red 

Receive Audio Green 

Squelch Input Black (optional) 


N OWNEF 


Using the provided cable, follow the colors above to match up with the 
manual, when you find it. 


By the way, I am reasonably computer literate, network literate and 
radio literate and I wouldn't attempt to do much with this TNC without 
the book. It's worth getting another copy from AEA, since the TNC is 
loaded with commands and features. 

-edg 
Ed Greenberg, WB2GOH/6 
San Jose, CA 
edg@netcom.COM 


Date: 17 Mar 91 02:39:05 GMT 

From: ogicse!unicorn!n9041169@ucsd.edu 
Subject: portable packet 

To: packet-radio@ucsd.edu 


I do not own a packet 

although I am thinking about buying one soon, one thing you might try though is 
purchasing one of the new breed of "notebook" size pc laptops. Most I have 
seen come with serial and parallel ports, vga lcd, screen and a fair amount 

of memory, and a 1.44mb 3.5in disk - all for between 1800-3600$. Zeos, Austin 
and a few others all make IBM compatible machines with 80286 12-16hz processors 
for about 2000 dolloars. Take a look in the March Computer Shopper for a run- 


down on most the latest of these notebook sized machines weighing generally 
less than 6l1b. 
hope you find what you're looking for, 
Chris 


Date: 14 Mar 91 19:37:07 GMT 

From: swrinde!cs.utexas.edu!ut-emx!ccwf.cc.utexas.edu!wdlee@ucsd.edu 
Subject: portable packet 

To: packet-radio@ucsd.edu 


I am planning a cross country expedition (by *RAIL*) and would like 
to take along my packet radio system. I have a couple of issues I'd like 
to discuss: 


DUMB TERMINALS (or, ‘Why is this lap-top so heavy?') 

My girlfriend agreed to loan me her laptop computer (bless her heart) 

but it just HURLS RF at 145.01 MHz. In addition, I'd just use it to run 
PROCOMM anyway. (It weighs more than my entire packet setup!) 

So I was at the mall this morning and saw something that 

I found intriguing (as Cmdr. Data would say). Have you seen the Casio 
B.0.S.S. model SF-9500? or model SF-800? These are little clock, calendar, 
memo, telephone number, rolodex, scratch your back, do everything hand-held 
LCD display things with little alpha-numeric keypads... and guess what... 
There's a serial port on the little guy and the literature states that 

"you can hook it up to your PC..."! 

Has anyone heard of any sort of modern little hand held LCD thing being used 
as a dumb (RS232) terminal? I'd only need a couple of lines (with scrollback 
perhaps) and I'd let my TNC do all the work. 


In closing, the other issue I was concerned about is... 

Should I even bother attempting to try 2 meter work from within a 

huge steel rail car moving at 80 mph? I love trains and have traveled coast 
to coast more than 10 times (I don't fly), and I have met other hams aboard 
the train with their HT's by their side. What do you think? 

All aboard! 

David 

their HT's on their belts 


Date: 14 Mar 91 22:40:55 GMT 

From: sdd.hp.com! zaphod.mps.ohio-state.edu! know! tegra!vail@ucsd.edu 
Subject: portable packet 

To: packet-radio@ucsd.edu 


In article <45605@ut-emx.uucp> wdlee@ccwf£.cc.utexas.edu (david lee) writes: 


DUMB TERMINALS (or, ‘Why is this lap-top so heavy?') 

My girlfriend agreed to loan me her laptop computer (bless her heart) 

but it just HURLS RF at 145.01 MHz. In addition, I'd just use it to run 
PROCOMM anyway. (It weighs more than my entire packet setup!) 

So I was at the mall this morning and saw something that 

I found intriguing (as Cmdr. Data would say). Have you seen the Casio 
B.0.S.S. model SF-9500? or model SF-800? These are little clock, calendar, 
memo, telephone number, rolodex, scratch your back, do everything hand-held 
LCD display things with little alpha-numeric keypads... and guess what... 
There's a serial port on the little guy and the literature states that 

"you can hook it up to your PC..."! 

Has anyone heard of any sort of modern little hand held LCD thing being used 
as a dumb (RS232) terminal? I'd only need a couple of lines (with scrollback 
perhaps) and I'd let my TNC do all the work. 


I had the idea of connecting tha cable from my BOSS into the speaker 
jack of my IC-24, put a NOS prompt on the screen and send it in to QST 
as portable packet. 


The answere to your question is: no. The BOSS will transfer data to 
another computer running the appropriate software with a simple Intel 
Hex based protocol. There is no "terminal mode" although I bet Casio 
could sell a few more BOSSs if they added one. 


The BOSS is a really neat and useful device although the only amateur 
radio uses I have found for it are alternate time (GMT) and saving 
repeater control codes and frequency information for reference. 


"theobromine: a compound which, contrary to it's name, 
contains neither bromine nor God" -- David Throop 
to es | Johnathan Vail | nidxg@tegra.com 
|Tegra| (508) 663-7435 | N1IDXG@448.625- (WorldNet) 
eee jv@nidxg.ampr.org {...sun!sunne ..uunet}!tegra! vail 


Date: 16 Mar 91 15:45:34 GMT 

From: swrinde!zaphod.mps.ohio-state.edu! pacific.mps.ohio-state.edu!linac, 
Subject: portable packet 

To: packet-radio@ucsd.edu 


In article <45605@ut-emx.uucp> wdlee@ccwf£.cc.utexas.edu (david lee) writes: 
>I am planning a cross country expedition (by *RAIL*) and would like 

>to take along my packet radio system. I have a couple of issues I'd like 
>to discuss: 


> 
>DUMB TERMINALS (or, 'Why is this lap-top so heavy?') 


A friend of mine uses his Sharp Wizard with a pocket packet TNC. The 
major problems are the screen and keyboard being smaller than standard. 
Most packeteers format their messages for 80 column and this makes it 
hard to read on a 40 col display. Secondly, the keyboards on these little 
jewels aren't really suited to touch typing. Keyboard QSOs are slow anyway, 
but having to hunt and peck on the little keyboard makes it intolerable 
to me anyway. The new Wizard (the one with the QWERTY keyboard) has a 
serial port that works up to 9600 baud. I don't know the baud rates 
available on the BOSS series. I have another friend who has one of 

these and I'll ask him. The consensus around here is that the Wizard 

is a better value than the BOSS, but if you're only going to use it 

as a terminal, then that probably doesn't matter. 


One lightweight system I've used for portable packet is the Radio 
Shack Mod 100. It suffers from the 40 col screen, but the keyboard is 
decent and it has a built in terminal program. Used Mod 100s should 

be lots cheaper than the BOSS or the Wizard. RCA used to make a simple 
dumb terminal with a 2 line 80 col display and a full size keyboard. 
These are a little smaller than a Mod 100 and I've seen them at 
hamfests for $25. 


Your HT should work fine on the train. I'd make a twinlead J-pole 

and tape it to a window for best results. Between your terminal and 
your TNC, there should be enough digital hash that I'd want to locate 
the antenna a few feet from the noise. Also the extra gain of the 
J-pole will help on voice too. 


Do be aware that train power may not be 110 VAC 60 Hertz. So battery 
elimination or charging may become a problem if you don't have the 
proper adapters. Check this out ahead of time with your travel agent 

or call the train company's maintence yard and talk to their electrician. 


Have fun! 


Gary KE4ZV 


Date: 19 Mar 91 03:45:33 GMT 

From: ARDSLEY.BUSINESS.UWO.CA!Mark@ucbvax.berkeley.edu 
Subject: SMTP Mail on PBBS? 

To: packet-radio@ucsd.edu 


I have been using KA9Q nos for quite a while now. I am interested in trying 
something else for awhile. Unforunately, I don't find NOS stable enough, or 


quick enough for AX25 use. I would like to have a bbs program that supports 
SMTP mail plus the messages come in as one file per user. Does anyone know of 
such a program? There is MSYS here, but it stores each message separately. 


Any ideas? 


Mark Bramwell, VE3PZR Located in sunny London, Ontario 


Internet: Mark@ARDSLEY.business.uwo.ca IP Address: 129.100.29.33 
Packet: VE3PZR @ VE3GYQ UWO Phone: (519) 661-3714 


Date: 21 Mar 91 17:13:28 GMT 

From: agate!eos!aio! gamorris@ucbvax.berkeley.edu 
Subject: STS-37 SAREX Information Summary 

To: packet-radio@ucsd.edu 


STS-37 SAREX 
Shuttle Amateur Radio EXperiment 
Information Summary 
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SAREX Introduction 


STS-37 Crew: 
N5RAW, Steve Nagel, Mission Commander 
KB5AWP, Ken Cameron, Pilot 
N5QWL, Jay Apt, Mission Specialist 


N5RAX, Linda Godwin, Mission Specialist 
N5SCW, Jerry Ross, Mission Specialist 


SAREX equipment on this flight includes a 2m (144-146 Mhz) Motorola radio 
(output 2.3 watts), Robot 1200C slow scan convertor, Heath HK-21 packet TNC, 
a 70cm FSTV receiver, a video camera, and a Monitor/VCR. Planned operations 
include voice contacts, packet robot, downlinking orbiter video via SSTV, 
uplinking FSTV video to the orbiter. 


During sleep periods and when no other SAREX activities are scheduled the 
equipment will be left on in packet robot mode. If time permits the crew 
will setup SAREX to transmit SSTV using orbiter video cameras during the GRO 
satellite release and during the EVA. The GRO satellite release is 
scheduled for MET 2/03:00 (2 days 3 hours after launch) for 1 hour. The EVA 
is scheduled for MET 2/22:00 thru MET 3/05:00. With 5 hams on the flight 
there may be many unscheduled opportunities for operation, I suggest you 
monitor both downlink frequencies on all passes starting with orbit 1 until 
landing, even during sleep periods you could hear something other than 
packet. Contacts between the shuttle and school children will be 
retransmitted by W5RRR, see timeline for times, and W5RRR frequency 
information below. 


Keplerian Element Set 

STS-37 

1 00037U 91 94.64868056 .00023000 17236-3 0 49 
2 00037 28.4683 237.6443 0006982 279.6613 80.3332 15.37985111 23 


Satellite: STS-37 


Epoch time: 91094 .64868056 

Element set: JSC-004 

Inclination: 28.4683 deg Space Shuttle Flight STS-37 

RA of node: 237.6443 deg Keplerian Elements 
Eccentricity: . 0006982 from pre-launch post OMS-2 vector 
Arg of perigee: 279.6613 deg Launch: 04 APR 91 14:20 UTC 
Mean anomaly: 80.3332 deg 

Mean motion: 15.37985111 rev/day W5RRR 

Decay rate: 2.30E-04 rev/day*%2 NASA Johnson Space Center 
Epoch rev: 2 


SAREX Uplink/Downlink Frequencies 


Downlink/Uplink Frequencies for Voice/Packet/SSTV to be used on Upcoming 
Mission 


Get out your HTUs and HT programming manuals. You will want to program your 
2 meter FM transceivers with the following information. Note that only 
stations with prior arrangements can uplink FSTV signals (special 
authorization is required from the FCC). It is expected that uplinking FSTV 
will require about 15kw ERP. FSTV ops and 2m can occur simultaneously. 


Mode Downlink Freq Uplink Freq 

Voice/SSTV 145.55 144.95 (primary), 144.91, 144.97 
Packet 145.51 144.91 (primary), 144.93, 144.99 
FSTV none 70cm band 


Please note that the frequencies they will be listening for stations ARE 
DIFFERENT than the one they will transmit on. This is a very important fact 
to understand. They will transmit to earth (downlink) on a single frequency 
145.55 MHz for voice and SSTV. They will listen for stations transmitting 
to the shuttle (uplink) on the other frequencies listed. This "split" 
operation is used quite successfully by DXers when operating in an 
environment where large pile ups are expected. 


There will be no simplex operation with SAREX on either voice or packet. 
Although packeteers are not accustomed to operation with a TX/RX offset, in 
this case, it is the only way to connect to SAREX. If you transmit on 
145.55 or 145.51 MHz the only people who will hear you are those other Hams 
in your area trying to hear the shuttle. 


SAREX Packet Operating Hints 


FULLDUP OFF 

DWAIT 0.1 - 0.5 seconds 
FRACK > 3.0 seconds 

C KB5AWP 


The packet call sign on board the shuttle is KB5AWP (SSID=0). Your TNC 
should be in half-duplex mode (FULLDUP OFF) with CD active just like you do 
for normal VHF packet operations. If you can compensate for doppler shift 
it is worth the extra effort. The bandwidth of the SAREX radio is +/-4Khz, 
maximum doppler is around 3.3Khz. If you canUt compensate for doppler your 
best chance for contact is when the shuttle is at peak elevation at your 
site. 


You should be careful with the setting of two of your TNC's timers: DWAIT 
and FRACK. DWAIT is the time interval after your Carrier Detect light goes 
out and before your transmitter turns on. You want to make sure your 
connects requests and ACKs are contained in the 3 second FUDtimer window. 


If everybody runs the same DWAIT (like the typical 0.1 - 0.5 second values 
used for terrestrial packet), then everybody will be transmitting at the 
same time. Part of the key to your success when uplink QRM is heavy is to 
pick a DWAIT that nobody else is using! (sort of like picking a lottery 
number! ) 


FRACK sets the time interval between your transmissions. After you send a 
frame, your TNC waits for the FRACK time, and then waits for the Carrier 
Detect signal to drop, then waits DWAIT, and then tries again. You should 
make sure your FRACK is at least 3 seconds so that you are not transmitting 
when the robot's FUDtimer decides it is time for it to transmit -- if you 
are transmitting at the same time, you will miss any packets the shuttle is 
addressing to you and you won't have a successful QSO. 


Note that your DWAIT (how soon do I transmit?) and FRACK (then how long do I 
wait?) parameters and the need to stop transmitting so you can hear a reply 
are just like you encounter when working a DXpedition pileup on HF. If the 
DX station has a pattern of listening for a few seconds (=FUDtimer) before 
transmitting, you may have better luck being the LAST station they hear, 
after the din dies down. The differences are that (1) the robot is a 
computer and is very predictable and (2) the robot can be working several 
stations at one time. 


Mission Audio Retransmissions 


The following stations will retransmit the mission audio from the shuttle 
and ground controllers. 


WA3NAN - Goddard Space Flight Center (GSFC), Greenbelt, Maryland. 
W5RRR- - Johnson Space Center (JSC), Houston, Texas 

W6VIO - Jet Propulsion Laboratory (JPL), Pasadena, California. 
W6FXN - Los Angeles 

K6MF - San Francisco 

W4MWG - Mebane, NC 


Station VHF 10m 15m 20m 40m 80m 


WA3NAN 147.45 28.650 21.395 14.295 7.185 3.860 
WSRRR 146.64 


W6VIO 224.04 21.340 14.270 
W6FXN 145.46 
K6MF 145.58 7.165 3.840 


NASA/JSC 171.15 
W4MWG 14.230 (SSTV) 


W5RRR Special Event Station 


W5RRR - Johnson Space Center (JSC) ARC, Houston, TX. Special event station 
with bulletins, updated element sets, and current flight information will be 
making contacts and answering questions using SSB on the HF bands. The 
frequencies are listed below. The special event station will start after 
launch and run up thru landing. W5RRR will also retransmit the audio from 
the contacts between STS-37 and schools. Three of the 5 bands will be in 
use at any given time, band selection will be determined by propagation 
(usually 10/15/20m daytime, 20/40/80m night). 


Station 10m 15m 20m 40m 80m 


W5RRR 28.400 21.350 14.280 7.227 3.850 (+/- QRM) 


WLAW Voice Bulletins 


W1AW will be broadcasting daily bulletins with updated information on SAREX 
during the flight. Voice bulletins are transmitted daily at 0230 UTC and 
Q530 UTC on the following frequencies: 


Station 10m 15m 17m 20m 40m 80m 


WIAW 28.590 21.390 18.160 14.290 7.290 3.990 


AMSAT Net Operations 


Information will also be available from the AMSAT net, tune in for 
bulletins. The net operates every week on: 


Sunday 1800-2100 UCT (international) 14.282 Mhz USB 
Tuesday 0130-0300 UCT (USA) 3.840 Mhz LSB 


JSC INFO BBS 


The Public Affairs Office at the Johnson Space Center operates a BBS to 
provide information to the public. Check this board for updates to the 
keplerian element sets during the flight. 


To access the BBS, call +1-713-483-2500 using 1200 baud, 8-N-1, at the ENTER 
NUMBER: prompt, enter "62511" and you will be connected to the BBS. Check 


file area 30 or 99 for latest element sets. 


NASA JSC's Electronic Space Information BBS is intended to provide 24-hour 
access to biographies of NASA officials and astronauts, news releases, space 
flight mission presskits and television schedules, space shuttle systems 
information, flight manifests and schedules, and other information about the 
Space program. 


NASA Select Video Broadcast 


The continental United States will receive NASA Select television, 24 hours 
a day throughout the mission, via: 


SATCOM F2R 

Transponder 13 

72 degrees West Longitude 
3960 MHz (Video) 

6.8 MHZ (Audio) 


MET (ST/DST) xx 
UTC D H M Rev Event PT CT EF 
4/4/91 1420 0 00 00 1 LAUNCH 0620 4/4 0820 0920 
4/4/91 2115 0 06 55 5 Start SAREX Setup 1315 4/4 1515 1615 
4/4/91 2120 007 00 5 Begin Pre-Sleep Activity 1320 4/4 1520 1620 
4/4/91 2140 0 07 20 5 Finish SAREX Setup 1340 4/4 1540 1640 
4/5/91 0020 01000 #=7 Begin Sleep Period 1620 4/4 1820 1920 
4/5/91 0820 018 00 12 Begin Post-Sleep Activity 0020 4/5 0220 0320 
4/5/91 1120 © 21 00 14 End Post-Sleep Activity 0320 4/5 0520 0620 
4/5/91 1210 © 21 50 15 Cabin depress to 10.2 PSI 0410 4/5 0610 0710 
4/5/91 1332 0 23 12 16 AOS FSTV w/N9AB, US Bridge 0532 4/5 0732 0832 
4/5/91 1350 0 23 30 16 LOS FSTV w/N9AB, US Bridge 0550 4/5 0750 0850 
4/5/91 1511 1 00 51 17 AOS School #1 via US Bridge 0711 4/5 0911 1011 
4/5/91 1529 1 0109 17 LOS School #1 via US Bridge 0729 4/5 0929 1029 
4/5/91 1649 1 02 29 18 AOS School #2 via US Bridge 0849 4/5 1049 1149 
4/5/91 1707 1 02 47 18 LOS School #2 via US Bridge 0907 4/5 1107 1207 
4/5/91 1829 1 04 09 19 AOS School #3 via US Bridge 1029 4/5 1229 1329 
4/5/91 1845 1 04 25 19 LOS School #3 via US Bridge 1045 4/5 1245 1345 
4/5/91 2020 1 06 00 20 Begin Pre-Sleep Activity 1220 4/5 1420 1520 
4/5/91 2020 1 06 00 20 AOS School #4 via SA Bridge 1220 4/5 1420 1520 
4/5/91 2041 1 06 21 20 LOS School #4 via SA Bridge 1241 4/5 1441 1541 
4/5/91 2320 109 00 22 Begin Sleep Period 1520 4/5 1720 1820 
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Gary Morris 
Lockheed, Houston, Texas 
N5QWC/W5RRR 
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Time), CT 


Begin Post-Sleep Activity 
End Post-Sleep Activity 
GRO Grapple 

GRO Unberth 

GRO Solar Array Deploy 


GRO High Gain Antenna Deploy 
AOS FSTV w/W5RRR, KE4PT w/US Bridge 
LOS FSTV w/W5RRR, KE4PT w/US Bridge 


GRO Release 

Begin Pre-Sleep Activity 
Begin Sleep Period 

Begin Post-Sleep Activity 
End Post-Sleep Activity 
Begin EVA Prep 
Unscheduled SSTV/Packet 
Airlock Depress/Egress 
Unscheduled SSTV/Packet 
Unscheduled SSTV/Packet 
Unscheduled SSTV/Packet 
Airlock Ingress/Repress 
Begin Pre-Sleep Activity 
Begin Sleep Period 

Begin Post-Sleep Activity 
End Post-Sleep Activity 
Cabin repress to 14.7 PSI 
AOS School #5 US Bridge 
LOS School #5 US Bridge 


AOS Backup FSTV or w/W5RRR US Bridg 
LOS Backup FSTV or w/W5RRR US Bridg 


Begin Pre-Sleep Activity 
Start SAREX Stow 

Finish SAREX Stow 

Begin Sleep Period 

Begin Post-Sleep Activity 
End Post-Sleep Activity 
Deorbit Burn 

EDW Landing 
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0931 
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1230 
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(Central Time) and ET (Eastern Time) starts as stan- 
changes to daylight savings time on April 7, 0200 local time. 


Internet: garym@telesoft.com 


UUCP: lobster! avocado! gamorris 


Phone: 


+1 713 283 5195 


Date: 23 Mar 91 01:21:04 GMT 

From: epic!karn@bellcore.bellcore.com 
Subject: TAPR meeting notes 

To: packet-radio@ucsd.edu 


In article <17671@sdcc6.ucsd.edu>, williams@beowulf.ucsd.edu (Paul Williamson) 
writes: 

|> 

|> A detailed blow-by-blow account of the 1991 TAPR Annual Meeting in Tucson 
|> is available for FTP on tomcat.gsfc.nasa.gov in /public/tapr/blowby.txt 

|> and on thumper.bellcore.com in /pub/ka9q/incoming/blowby.txt (until Phil 

|> moves it to a permanent location). 


I've moved it to /pub/ka9q/misc/blowby.txt. 
Phil 


Date: 18 Mar 91 00:48:18 GMT 

From: usc!elroy.jpl.nasa.gov!sdd.hp.com! zaphod.mps.ohio-state.edu!rpi!uupsi! phage! 
helix.cshl.org!markiewi@ucsd.edu 

Subject: TCP/IP 

To: packet-radio@ucsd.edu 


Can someone offer me a hand? I am new to both the Internet, and to packet 
so please bear with me. I have a PK232 and am ineterested in using the 
KA9Q TCP/IP package with it. Does anyone have a basic document that they 
could mail me on the proper techniques of its use? How does one obtain 
their address? etc. Any help would be greatly appreciated. . 


Thanks, Peter N2IFC 


Date: 18 Mar 91 23:05:35 GMT 

From: sdd.hp.com!usc!rpi!uupsi! phage! helix.cshl.org!markiewi@ucsd.edu 
Subject: Thanks 

To: packet-radio@ucsd.edu 


Thanks to all the people who responded to my posting yesterday. I 
think I have all the info I need, or atleast were I can find it. 


Thanks again, Peter N2IFC 


Date: 19 Mar 91 02:57:23 GMT 

From: uvaarpa!haven! boingo.med.jhu.edu!aplcen! wb3ffv!howardl@mcnc.org 
Subject: The Amateur Radio BBS - How to access 

To: packet-radio@ucsd.edu 


HOW TO ACCESS THE WB3FFV AMATEUR RADIO TELEPHONE BBS !!! 


I have placed a BBS system on-line that is mainly oriented towards the 
Amateur Community (but there is other stuff on-line). As of now I have not 
attempted to promote this system any place except in the amateur channels 
(PACKET, USENET, & word of mouth), and will continue under this policy, as 
I hope to keep it oriented toward amateur radio. The various software for 
UP/DOWNload is available via telephone dialup and Packet TCP/IP, and through 
user support I hope to keep the latest and greatest ham software on-line. 
Below is the information that is needed in order to access the BBS via 
Telephone -or- TCP/IP, please pass it around to as many ham's as possible. 


System Name: WB3FFV 

User Login: bbs 

Number: (301)-625-0817 -- 1200 & 2400 (Non-MNP) 

Number: (301) -625-9482 -- 1200,2400,4800,9600,19200,38400 V.32 (V.42bis/MNP5) 

Number: (301) -625-9663 -- 1200 & 2400 (MNP5), 9600 & 19200 (PEP) 

Data Settings: 8 Bits, NO Parity, 1 Stop Bit 

Times: 24hrs/365days (except for routine maintenance) 

Software: XBBS (UNIX/Xenix Multiuser BBS) 

IP Address: 44.60.128.1 {wb3ffv.ampr.org? [for FTP access on 145.650 mhz ONLY] 

Misc. Info: Machine is an 80486 computer running UNIX V.3.2 and features 800 
Meg of on-line storage. Most transfer protocols are available!! 


I attempt to keep the latest and greatest HAM software on-line, and encourage 
all to upload anything new that they come up with, as it is of benefit to all. 
Here is a sample of a couple pieces of software that is available for DOWNLOAD: 


KA9Q TCP/IP Software for the PC (Latest OFFICIAL release + TEST Versions) 
KA9Q TCP/IP for the Atari-ST, MAC, & Amiga 

KA9Q TCP/IP for UNIX based systems 

KA9Q TCP/IP (The NOS release) [UNIX, MS/DOS, Amiga] 

KA9Q TCP/IP (Version by G1EMM, PE1CHL, PAOGRI, Etc.) 

N2GTE Packet Mail Switch [GTEPMS] (Version 1.2) 

WA7MBL BBS for the PC (Versions 3.31, 4.31 & 5.1[2,3,4]) 

WORLI BBS for the PC (Versions 6.xx, 7.xx, 8.xx, 9.xx, 10.xx, 11.xx) 
MSYS BBS for the PC running KISS TNC's’ (Version 1.07-1.10) 

AA4SRE BBS for the PC (Version 2.10) 

Various BBS utilities and enhancements 


Several MORSE CODE Tutors 

TheNet software by NORD><LINK (Version 1.01 & 2.06) 
Modifications for many HAM Rigs and Scanners 
Digital Signal Processing software (DSP) 

DX and contesting programs 

ARRL Newsletters & Gateway 

W5YI Electronic Edition 


There is much more available on the BBS, and I don't want to waste a lot of 
PACKET BBS space trying to list it all, so if you are interested give ita 
call and see for yourself !!! 


If you are interested in using UUCP to connect to the BBS, this can also be 
done as I support Anon-uucp. The login to the system is ‘uucpanon', and there 
is NO password. The listing of avalible archives are stored in a file called 
'FILES', and it is located in the /usr/spool/uucppublic. To retrieve the files 
listing just use the following command: 


uucp wb3ffv!~/FILES /usr/spool/uucppublic 


This will move a copy of my files listing into your uucppublic directory. If 
you have any questions or problems, feel free to contact me at one of the 
numbers/adresses below. Good Luck... 


Date: 19 Mar 91 02:53:46 GMT 

From: uvaarpa!haven! boingo.med.jhu.edu!aplcen! wb3ffv!howardl@mcnc.org 
Subject: The N2GTE Packet Mail Switch 

To: packet-radio@ucsd.edu 


Hello All, 


As I promised about two weeks ago, here is a little more detail on the N2GTE 
Packet Mail Switch. I would have written back sooner, but getting the flu 
caused my bed to take priority over Email :-( 


Many of you on here have talked about the problems with the TCP/IP section of 
the MSYS package, but here is a BBS (if you want to run a BBS) that won't have 
the problems listed since it actually uses NET (from Phil - KA9Q) so everything 
should work. 


The BBS is a multi-user/multi-tasking system that runs inside of DesqView 2.3x 
and uses DesqView like I have seen no other packaged do. To achive very good 

efficiency it uses multiple windows to acomplish it's tasks, and will open and 
close user and forwarding windows as needed. 


Also one unique feature of the BBS is it's ability to learn new routes to other 


BBS systems. GTEPMS if not sure how to resolve a message, will send a request 
to other GTEPMS systems in the area and ask them if they know how to resolve 
the mail, and if so it will learn the path and add it to it's own tables. 


I won't go into a big thing here on just what all the BBS will do, but will 
leave info below on how you can download the doc's if you desire. 


Where I really like this BBS program is in it's ability to exchange mail 
between the BBS and NET. I a message arrives on the BBS and it is destined 
for an IP address (.AMPR, .AMPR.ORG, or whatever you specify), or the user 
is listed in the forward file. The BBS will place the message in the 
SPOOL\MQUEUE directory and setup the job for SMTP transfer. Also if a job 
arrives via SMTP and the next host can't be found in the HOSTS table ( this 
assumes you have it set to place the unresolved jobs in RQUEUE), and the 
job gets placed in SPOOL\RQUEUE. The GTEPMS system will scan the RQUEUE 
directory and attempt to resolve the message. So if the unresolved message 
was for say W3XYZ @ WB3FFV.MD.USA.NA, it will accept that message and place 
it in the BBS for forwarding in the BBS network. 


As you can see this provides a complete gateway between the BBS and TCP/IP 
worlds, and avoids many of the problem IP implementations in other BBS 
systems by actaully using NET. I personally wanted to receive the local 
BBS bulletins (and used the IP mbox, but it had many problems), but wasn't 
willing to stop running NET/NOS to do this. This BBS package (GTEPMS) has 
allowed me to do both, and since becoming a beta tester for Doug's code I 
have very much enjoyed the package. 


One thing that should NOT be overlooked, this is a BIG system and requires 
the mimimum configuration listed below: 


80286 based system (The faster the better) 4386 if at all possible} 
Desqview 2.3x (QEMM-386 5.x if using a 386) 

2Meg of DRAM (4Meg if also using NET) 

G8BPQ PC-Node Software (Version 3.57 to 3.59) 

GTEPMS Version 1.2 (o£ course :-) 


I personally use an 80386sx-20 with 4MB of RAM to run the system, but with 
this configuration I can also use TC++ at the same time! 


OK, so you want to know where you can get the software. The code can be 
downloaded from my telephone BBS, and I will once again post in a seperate 
message the information on how to reach my BBS. I will also try and post 
the files on thumper and tomcat over the next couple days when I have time 
to upload them, but for now it is only on the BBS. 


Hopefully this will answer the questions some of you have on the BBS, and if 


you decided to try it I would really like to hear what you think of it as well.. 


Internet : howardl@wb3ffv.ampr.org | Howard D. Leadmon 


UUCP : wb3ffv!howardl | Advanced Business Solutions 
TELEX : 152252474 | 210 E. Lombard St - Suite 410 
FAX : (301) -244-8790 | Baltimore, MD 21202 
PACKET : WB3FFV @ WB3FFV.MD.USA.NA | Phone: (301) -576-8635 


Date: 20 Mar 91 23:59:37 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: TNC Emulators on PC's 
To: packet-radio@ucsd.edu 


Some time ago, a European software package was announced that could 
emulate a TNC on an IBM PC or PC Clone. Besides that package, are 
there any other IBM clones TNC emulators around? 


Date: 21 Mar 91 00:28:45 GMT 

From: theory.tn.cornell.edu! payne@THEORY.TN.CORNELL.EDU 
Subject: TNC Emulators on PC's 

To: packet-radio@ucsd.edu 


In article <9103202358.AA23474@ucsd.edu> GIDEN@WSUVM1.CSC.WSU.EDU (Robert Giden 
N7KCG) writes: 

>Some time ago, a European software package was announced that could 

>emulate a TNC on an IBM PC or PC Clone. Besides that package, are 

>there any other IBM clones TNC emulators around? 


Yes, there is. I've written a program called PMP (Poor Man's Packet) 
that is in use here in the Ithaca, NY area. The gory details of the serial 
protocol are not as cleanly implemented as Baycom (my program hangs the 
machine during RX and TX) and I don't have as many features as Baycom. 

But overall, I think my program is much more cleanly implemented (overall 
structure, user interface, configuration). 


Originally, I was going to make the program shareware. Now, with 
the usual lack of time, I'm giving it away as "guiltware"--send me what 
you think it is worth. I offer no guarantees; I may never get around to 
fixing bugs. But I will give you some help: full source code (Turbo C). 


If there is any interest, I will make it available via anonymous 


Andrew C. Payne, N8KEI UUCP: ...!cornell!batcomputer! payne 
INTERNET: payne@tcgould.tn.cornell.edu 


Date: 21 Mar 91 21:55:06 GMT 

From: usc!wuarchive!waikato.ac.nz!comp.vuw.ac.nz!cc-server4.massey.ac.nz! 
G.Moretti@ucsd.edu 

Subject: TNC Emulators on PC's 

To: packet-radio@ucsd.edu 


>>> Re PMP - A user's comments 
An excellent program. I've been using it for about a year and it 
works well. Several other users down in this part of the world have 


been using it quite successfully too ... 


One disadvantage (which apparently is shared by BAYCOM) is that you 
cannot upload/download binary files (no YAPP/XMODEM ...) support. 


I've been using the second parallel port, but as the port address, the 
active bit and which level is active are defined in the config file 
(PMP.CFG) you should be able to use either serial or parallel port to 
talk to the modem. 

The modem side is simply a 7910 based modem for 1200 baud. 


These comments apply to PMP version 0.93. Andy may have released a 
later version. 


Cheers 
Giovanni ZL2BOI 


Giovanni Moretti, Consultant | G.Moretti@massey.ac.nz, Pkt-ZL2BOI@ZL2BF3I 
Computer Centre, Massey University| Ph 64 63 69099 x8398, FAX 64 63 505607 
Palmerston North, New Zealand | QUITTERS NEVER WIN, WINNERS NEVER QUIT 


Date: 20 Mar 91 15:26:23 GMT 

From: usc!apple!well! kdavis%well.sf.ca.us@ucsd.edu 
Subject: WANTED: Docs for NETPC (DL3DBT v891105) 
To: packet-radio@ucsd.edu 


I am running the net.exe called netpc developed in Germany by 
DL3DBT and group. I have it running fine on two ports with 
tcp/ip and net/rom. 


I need the documentation for this (in English, I hope). Many features 
like NOS are handled with this program and it has color and windowing 
support. 


If anyone knows where I can ftp the docs please contact me. Thanks! 


-- Ken 


Date: 21 Mar 91 17:57:32 GMT 

From: agate! apple! veritas!amdcad!sono!collins@ucbvax.berkeley.edu 
Subject: Where can I download Baycom? 

To: packet-radio@ucsd.edu 


I am looking for a copy of Baycom and noticed in a previous 
posting that someone (don't remember who, unfortunately) 
mentioned downloading it. Does anyone know of a site which 
has Baycom and which could e-mail a uuencode'd copy (I do 
not have £tp access)? 


Thanks in advance, 


Michael Stratford Collins 
collins@sono.uucp 
sun!sono!collins 


Date: (null) 

From: (null) 

And while I'm pontificating (:-) the left most callsign (in the above 
examples 

VK6ZIM) should ONLY be considered for routing purposes if it is shown as part 
of the domain segment (eg VK6ZIM.VK6BBS.#WA.AUS). Once the '@' is reached in 
the right to left scan, routing should stop. The reason is this: the 
originator 

of the message may know that VK6ZJM has moved QTH - routing software wouldn't 
always know this. 


HVVV VV VV VV 


think that when someone moves the first person they tell (in the packet 
world) is the SYSOP of their local BBS, otherwise that BBS is going to keep 


trying to forward mail to them when they're not there. Being able to forward 
on the TO field is often very useful - remote SYSOPs often like to have mail 
addressed to SYSOP forwarded on to them, for example. 


Brian Lloyd 


Software Management & Control, # By e-mail : blloyd@axion.bt.co.uk 
Software Technology Division, 4 By Phone : +44 (0)473 646650 
SSTF Building, BTRL, Martlesham Heath, dF By Fax : +44 (0)473 643019 
Ipswich, Suffolk. UK. IP5 7RE d## By Packet : GINNA@GB7NNA.GBR.EU 


Date: 19 Mar 91 05:01:47 GMT 
From: gatech!udel!haven!ni.umd.edu!sayshell.umd.edu! louie@ucsd.edu 
To: packet-radio@ucsd.edu 


References <7492.27e484b1@cc.curtin.edu.au>, 
<1991Mar18.150624.23335@axion.bt.co.uk>, 
<1991Mar18. 215239 .19274@casbah.acns.nwu.edu> 
Subject : Re: Hierarchical Forwarding pounds (#4) 


In article <1991Mar18.215239.19274@casbah.acns.nwu.edu> hpa@casbah.acns.nwu.edu 
(Peter Anvin) writes: 

>In proper domain-style addressing, a la the Internet, this would rather be: 

> 


>Do I know where VK6ZJM.WA.AUS is? No 
>Do I know where WA.AUS is? No 
>Do I know where AUS is? Yes 
>Forward in direction AUS 

> 


Bzzzzzt - wrong. In domain-style "addresses", names are just names, 
and DO NOT imply routes. There are names, addresses, and routes; it 
is important to keep the distinction between each of them. 


Internet style names are broken into an administrative heirarchy which has 
(by design and absolute intent) nothing to do with routing or addresses. 


If you are going to cite Internet style domain names, please don't change 
the meaning while you're at it. 


Yes, some of us are really sensitive about this distinction. 


louie 
WA3YMH 


Date: 19 Mar 91 10:35:36 GMT 

From: ucselx!bionet!apple!mips!spool.mu.edu!munnari.oz.au!manuel! 
csc.canberra.edu.au! echo! skcm@ucsd.edu 

To: packet-radio@ucsd.edu 


References <1991Mar15.025040.16086@maverick.ksu.ksu.edu>, 
<1991Mar16.202548 .18162@ims.alaska.edu>, <7492.27e484b1@cc.curtin.edu.au> 
Subject : Re: Hierarchical Forwarding pounds (4) 


In <7492.27e484b1@cc.curtin.edu.au> Murray_RJ@cc.curtin.edu.au (Ron Murray) 
writes: 

>> the octothorpe, ‘#'. 

>2. Someone in Australia mis-read the documentation and decided that this name 
> change was necessary. This is probably the more likely. 


FAR FAR more likely. :-) Browsing thru the mail on my BBS (VKLKCM) I notice 
South Australia and Western Australia both use the "#" at the state level 
while everybody else only uses it below the state. (4#SA, #WA and ACT, NSW etc) 


It's rare, however, for there to be any identifiers below the state level. 
My address here in Canberra is; 
vkikcm@vkikem.act.aus.oc 


Also the "Asianet" sysops, mainly Brian Beamish Vk4BBS decided that we wouldn't 
use .au aS our domain. Instead we have to use .oc (for Oceania). Needless to 
say none of these people are on the internet. :-( 


Date: 15 Mar 91 03:12:15 GMT 

From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com! uakari.primate.wisc.edu!umriscc! 
maverick.ksu.ksu.edu!matt.ksu.ksu.edu!steve@ucsd.edu 

To: packet-radio@ucsd.edu 


References <47@norand.UUCP>, <29868@ucsd.Edu>, 
<1991Mar13 . 212921 .31032@cunixf.cc.columbia.edu>ck.ks 
Subject : Re: Digital repeater network 


>Has anyone looked into the feasibility of creating a digital repeater network? 
>It seems to me that this would allow most any ham to talk to most any other, 
>anywhere, using a simple handheld radio. This seems like a logical extension 
>of the current plans to create an analog system using dynamic links to a 

>long distance backbone. The problem with this scheme is: what happens 


>if a link in the backbone fails; and if more than one user wants to use the 
>system at the same time? It would be a very resource intensive system, 
>anyway. 


I have thought of this idea. With current A/D and DSP technology, it 
would be easy to build a fully Digital Audio Repeater (DAR). Just convert 
the received audio with an A-to-D, add filtering/CW tones/ect 

with a DSP and spit out the result using a D-to-A. If 

output to a network is wanted, just send the digital streams 

to a RF modem as well as the transmitter. Also, voice mail could 

easily be implemented with the addition of secondary storage. (it could 
even be transferred as normal mail over conventional packet channels.) 


>In short: why couldn't the Amateur community set up the equivalent of a 
>digital cellular network with modest user requirements, linked exclusively 
>by radio and therefore immune to damage to the hard-wired systems such as 
>the telephone network. 


A similar 'what if' was presented at the _9th Computer Networking Conference_ 
by Jon Bloom, KE3Z. The technology is getting there, but it will take 

even more time before the idea catches on. We have a large base of 

old technology voice repeaters that will not go away. :-) 


-Steve Schallehn, KBOAGD 
Kansas State University 


Date: (null) 
From: (null) 
--Kauto, OH5LFM 


KAKKKKKKKKKKKKKKKA Kauto Huopio (huopioWkannel .LUt. £1) *xAKAKAKKRAKK AAA KARE 


*x Mail: Kauto Huopio, Punkkerikatu 1 A 10, SF-53850 Lappeenranta,Finland x 
KAKKAIKKKAIKK KIRK KKK KKK KA KIARA KAKA KAKA KKK K IKK K AKA K AKI K IKI K IKI K IKARIA IRI IRIER ERIK 


Date: 20 Mar 91 02:49:36 GMT 

From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com! zaphod.mps.ohio-state.edu! 
casbah.acns.nwu.edu! hpa@ucsd.edu 

To: packet-radio@ucsd.edu 


References <1991Mar18 .150624.23335@axion.bt.co.uk>, 
<1991Mar18 . 215239 .19274@casbah.acns.nwu.edu>, <1991Mar19.050147.911@ni.umd.edu> 
Subject : Re: Hierarchical Forwarding pounds (4) 


In article <1991Mar19.050147.911@ni.umd.edu> louie@sayshell.umd.edu (Louis A. 
Mamakos) writes: 

>Bzzzzzt - wrong. In domain-style "addresses", names are just names, 

>and DO NOT imply routes. There are names, addresses, and routes; it 

>is important to keep the distinction between each of them. 

> 

>Internet style names are broken into an administrative heirarchy which has 
>(by design and absolute intent) nothing to do with routing or addresses. 

> 

>If you are going to cite Internet style domain names, please don't change 
>the meaning while you're at it. 


I stand corrected -- to a degree. What I should have said, I guess, would 
be something like “this is the intent of hierarchial xxaddressingxx' ' 


As you correctly point out, Internet host names are hierarchial but do not 
necessarily imply addressing. They do if and only if they point to a 
non-IP subdomain for mail traffic, such as fidonet.org, where routing is 
provided through UUCP to different gateways depending on a specified 
subdomain. 


In the store-and-forward landline network Fidonet, addresses are 
hierarchial but numerical on the form 


NNN: NNN/NNN.NNN (the punctuation allows for abbreviation only) 
The Fidonet address is left-major, opposite the direction of the Internet 
and Amateur Packet hierarchial names, but partially similar to the IP 


numbering system (NNN.NNN.NNN.NNN). 


If a system is to send mail to, say, 2:206/203.1 it uses an algorithm like 
this: 


[THIS IS VERY SIMPLIFIED AS ANYONE FAMILIAR WITH FIDONET WOULD SEE 


IMMEDIATELY ] 

Do I have a route to 2:206/203.1? No 

Do I have a route to 2:206/203.0? No 

Do I have a route to 2:206/0.0? No 

Do I have a route to zone 2? YES - 1:115/500.0 -> forward 


The amateur AX.25 network is different from Fidonet, Internet and UUCP in 
topology, nature of the nodes, the information each node has, and 
addressing format. Thus what applies to one does not necessarily aplpy to 
the other. That doesn't prevent us from learning from each other and find 
a good combination of techniques needed for each individual network. 


/Peter 


hpa = H. Peter Anvin (in case you wondered) x Heja Sverige! 
INTERNET: hpa@casbah.acns.nwu.edu FIDONET: 1:115/989.4 
HAM RADIO: N9OITP, SMATKN RBBSNET: 8:970/101.4 


Date: (null) 

From: (null) 

The idea of scanning from left to right is to find the most direct route to 
the destination. If I was to forward a message to you, the BBS would perform 
the following steps : 


Do I know where VK6ZJM is? 

No - do I know where VK6BBS is? 

No - do I know where #WA is? 

No - do I know where AUS is? 

Yes - forward the message in that direction. 


If, on the other hand, I had a direct link to VK6BBS I would forward the 
message there, rather than to Australia, as VK6BBS is much closer to you 
Australia in general. 


The main reason for having the # before the second field is to eliminate any 
problem which may arise from having a local hierarchical address which is 
the same as a country or continent designator. If, for example, you had a 
local address of NA (for Northern Australia, say), then the BBS would try to 
send the message to North America, as that is what NA is supposed to be. 


I hope this helps a bit. 


Brian 
(GINNA@GB7NNA. GBR. EU) 


End of Packet-Radio Digest 
FOI I a 


